Worker guide; Add note about what pools support what

docs/userguide/workers.rst

@@ -103,6 +103,10 @@ specify a file for these to be stored in, either by using the `--statedb`
 argument to :mod:`~celery.bin.celeryd` or the :setting:`CELERYD_STATE_DB`
 setting.  See :setting:`CELERYD_STATE_DB` for more information.
 
+Note that remote control commands must be working for revokes to work.
+Remote control commands are only supported by the amqp, redis and mongodb
+transports at this point.
+
 .. _worker-time-limits:
 
 Time limits
@@ -110,6 +114,8 @@ Time limits
 
 .. versionadded:: 2.0
 
+:supported pools: processes
+
 A single task can potentially run forever, if you have lots of tasks
 waiting for some event that will never happen you will block the worker
 from processing new tasks indefinitely.  The best way to defend against
@@ -166,6 +172,8 @@ Max tasks per child setting
 
 .. versionadded:: 2.0
 
+:supported pools: processes
+
 With this option you can configure the maximum number of tasks
 a worker can execute before it's replaced by a new process.
 
@@ -182,6 +190,8 @@ Autoreloading
 
 .. versionadded:: 2.5
 
+:supported pools: processes, eventlet, gevent, threads, solo
+
 Starting :program:`celeryd` with the :option:`--autoreload` option will
 enable the worker to watch for file system changes to all imported task
 modules imported (and also any non-task modules added to the
@@ -231,6 +241,9 @@ Remote control
 
 .. versionadded:: 2.0
 
+:supported pools: processes, eventlet, gevent, blocking:threads/solo (see note)
+:supported transports: amqp, redis, mongodb
+
 Workers have the ability to be remote controlled using a high-priority
 broadcast message queue.  The commands can be directed to all, or a specific
 list of workers.
@@ -255,6 +268,13 @@ to the number of destination hosts.
     commands from the command line.  It supports all of the commands
     listed below.  See :ref:`monitoring-celeryctl` for more information.
 
+.. note::
+
+    The solo and threads pool supports remote control commands,
+    but any task executing will block any waiting control command,
+    so it is of limited use if the worker is very busy.  In that
+    case you must increase the timeout waitin for replies in the client.
+
 .. _worker-broadcast-fun:
 
 The :meth:`~@control.broadcast` function.