Use 'CALL a task' for client, and 'EXECUTE' for worker

Changelog

@@ -3707,7 +3707,7 @@ Changes
 * Added new entries to the :doc:`FAQs <faq>`:
 
     * Should I use retry or acks_late?
-    * Can I execute a task by name?
+    * Can I call a task by name?
 
 .. _version-1.0.4:
 

docs/configuration.rst

@@ -135,7 +135,7 @@ Concurrency settings
 CELERYD_CONCURRENCY
 ~~~~~~~~~~~~~~~~~~~
 
-The number of concurrent worker processes/threads/green threads, executing
+The number of concurrent worker processes/threads/green threads executing
 tasks.
 
 If you're doing mostly I/O you can have more processes,
@@ -200,7 +200,7 @@ Can be one of the following:
 .. warning:
 
     While the AMQP result backend is very efficient, you must make sure
-    you only receive the same result once.  See :doc:`userguide/executing`).
+    you only receive the same result once.  See :doc:`userguide/calling`).
 
 .. _`SQLAlchemy`: http://sqlalchemy.org
 .. _`memcached`: http://memcached.org
@@ -214,7 +214,7 @@ CELERY_RESULT_SERIALIZER
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 Result serialization format.  Default is `"pickle"`. See
-:ref:`executing-serializers` for information about supported
+:ref:`calling-serializers` for information about supported
 serialization formats.
 
 .. _conf-database-result-backend:
@@ -863,7 +863,7 @@ methods that have been registered with :mod:`kombu.serialization.registry`.
 
 .. seealso::
 
-    :ref:`executing-serializers`.
+    :ref:`calling-serializers`.
 
 .. setting:: CELERY_TASK_PUBLISH_RETRY
 
@@ -1226,7 +1226,7 @@ CELERY_EVENT_SERIALIZER
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 Message serialization format used when sending event messages.
-Default is `"json"`. See :ref:`executing-serializers`.
+Default is `"json"`. See :ref:`calling-serializers`.
 
 .. _conf-broadcast:
 

docs/django/first-steps-with-django.rst

@@ -53,8 +53,8 @@ include the following in your ``.wsgi`` module::
     import djcelery
     djcelery.setup_loader()
 
-Defining and executing tasks
-============================
+Defining and calling tasks
+==========================
 
 Tasks are defined by wrapping functions in the ``@task`` decorator.
 It is a common practice to put these in their own module named ``tasks.py``,
@@ -98,11 +98,11 @@ For a complete listing of the command line options available, use the help comma
 .. _`Running Celery as a Daemon`:
     http://docs.celeryproject.org/en/latest/tutorials/daemonizing.html
 
-Executing our task
-==================
+Calling our task
+================
 
 Now that the worker is running we can open up a new terminal to actually
-execute our task::
+call our task::
 
     >>> from celerytest.tasks import add
 
@@ -111,17 +111,16 @@ execute our task::
 
 The ``delay`` method is a handy shortcut to the ``apply_async`` method which
 enables you to have greater control of the task execution.
-To read more about executing tasks, including specifying the time at which
-the task should execute see :ref:`guide-executing`.
+To read more about calling tasks, including specifying the time at which
+the task should be processed see :ref:`guide-calling`.
 
 .. note::
 
     Tasks need to be stored in a real module, they can't
-    be defined in the python shell or ipython/bpython. This is because the
-    worker server must be able to import the task function so that it can
-    execute it.
+    be defined in the python shell or IPython/bpython. This is because the
+    worker server must be able to import the task function.
 
-The task should now be executed by the worker you started earlier,
+The task should now be processed by the worker you started earlier,
 and you can verify that by looking at the workers console output.
 
 Applying a task returns an :class:`~celery.result.AsyncResult` instance,
@@ -132,7 +131,7 @@ By default django-celery stores this state in the Django database,
 you may consider choosing an alternate result backend or disabling
 states alltogether (see :ref:`task-result-backends`).
 
-To demonstrate how the results work we can execute the task again,
+To demonstrate how the results work we can call the task again,
 but this time keep the result instance returned::
 
     >>> result = add.delay(4, 4)

docs/faq.rst

@@ -601,11 +601,11 @@ queue for exchange, so that rejected messages is moved there.
 
 .. _faq-execute-task-by-name:
 
-Can I execute a task by name?
+Can I call a task by name?
 -----------------------------
 
 **Answer**: Yes. Use :func:`celery.execute.send_task`.
-You can also execute a task by name from any language
+You can also call a task by name from any language
 that has an AMQP client.
 
     >>> from celery.execute import send_task

docs/getting-started/first-steps-with-celery.rst

@@ -17,8 +17,9 @@ You will learn about;
 
 - Choosing and installing a message broker.
 - Installing Celery and creating your first task
-- Starting the worker and executing tasks.
-- Keeping track of tasks as they execute, and inspecting return values.
+- Starting the worker and calling tasks.
+- Keeping track of tasks as they transition through different states,
+  and inspecting return values.
 
 Celery may seem daunting at first - but don't worry - this tutorial
 will get you started in no time. It is deliberately kept simple, so
@@ -155,22 +156,21 @@ There also several other commands available, and help is also available::
 
 .. _`supervisord`: http://supervisord.org
 
-.. _celerytut-executing-task:
+.. _celerytut-calling:
 
-Executing the task
-==================
+Calling the task
+================
 
-Whenever we want to execute our task, we use the
-:meth:`~@Task.delay` method of the task.
+To call our task we can use the :meth:`~@Task.delay` method.
 
 This is a handy shortcut to the :meth:`~@Task.apply_async`
 method which gives greater control of the task execution (see
-:ref:`guide-executing`)::
+:ref:`guide-calling`)::
 
     >>> from tasks import add
     >>> add.delay(4, 4)
 
-The task should now be executed by the worker you started earlier,
+The task should now be processed by the worker you started earlier,
 and you can verify that by looking at the workers console output.
 
 Applying a task returns an :class:`~@AsyncResult` instance,
@@ -208,7 +208,7 @@ the message broker (a popular combination)::
 
 To read more about result backends please see :ref:`task-result-backends`.
 
-Now with the result backend configured, let's execute the task again.
+Now with the result backend configured, let's call the task again.
 This time we'll hold on to the :class:`~@AsyncResult` instance returned
 when you apply a task::
 
@@ -328,7 +328,7 @@ route a misbehaving task to a dedicated queue:
     }
 
 Or instead of routing it you could rate limit the task
-instead, so that only 10 tasks of this type can execute in a minute
+instead, so that only 10 tasks of this type can be processed in a minute
 (10/m):
 
 :file:`celeryconfig.py`:
@@ -356,4 +356,4 @@ Where to go from here
 =====================
 
 After this you should read the :ref:`guide`. Specifically
-:ref:`guide-tasks` and :ref:`guide-executing`.
+:ref:`guide-tasks` and :ref:`guide-calling`.

docs/getting-started/intro.rst

@@ -64,7 +64,7 @@ Celery is…
 
     - **Fast**
 
-        A single Celery process can execute millions of tasks a minute,
+        A single Celery process can process millions of tasks a minute,
         with sub-millisecond round-trip latency (using RabbitMQ,
         py-librabbitmq, and optimized settings).
 
@@ -197,3 +197,22 @@ Celery is…
         - :ref:`get a list of people and companies using Celery <res-using-celery>`
         - :ref:`write my own remote control command <worker-custom-control-commands>`
         - change worker queues at runtime
+
+.. topic:: Jump to ⟶
+
+    .. hlist::
+        :columns: 4
+
+        - :ref:`Brokers <brokers>`
+        - :ref:`Tasks <guide-tasks>`
+        - :ref:`Calling <guide-calling>`
+        - :ref:`Workers <guide-workers>`
+        - :ref:`Monitoring <guide-monitoring>`
+        - :ref:`Optimizing <guide-optimizing>`
+        - :ref:`Security <guide-security>`
+        - :ref:`Routing <guide-routing>`
+        - :ref:`Configuration Reference <configuration>`
+        - :ref:`Django <django>`
+        - :ref:`Contributing <contributing>`
+        - :ref:`Signals <signals>`
+        - :ref:`FAQ <faq>`

docs/reference/celery.rst

@@ -161,7 +161,7 @@ Application
 
         Send task by **name**.
 
-        :param name: Name of task to execute (e.g. `"tasks.add"`).
+        :param name: Name of task to call (e.g. `"tasks.add"`).
         :keyword result_cls: Specify custom result class. Default is
             using :meth:`AsyncResult`.
 
@@ -349,7 +349,7 @@ Grouping Tasks
 
     .. method:: apply(args=(), kwargs={}, **options)
 
-        Same as :meth:`apply_async` but executes inline instead
+        Same as :meth:`apply_async` but executed the task inline instead
         of sending a task message.
 
     .. method:: clone(args=(), kwargs={}, **options)

docs/userguide/executing.rst → docs/userguide/calling.rst

@@ -1,22 +1,22 @@
-.. _guide-executing:
+.. _guide-calling:
 
 =================
- Executing Tasks
+ Calling Tasks
 =================
 
 .. contents::
     :local:
 
 
-.. _executing-basics:
+.. _calling-basics:
 
 Basics
 ======
 
-Executing a task is done with :meth:`~@Task.apply_async`,
-or its shortcut: :meth:`~@Task.delay`.
+Calling a task is done using :meth:`~@Task.apply_async`,
+or the meth:`~@Task.delay` shortcut.
 
-:meth:`~@Task.delay` is simple and convenient, as it looks like calling a regular
+:meth:`~@Task.delay` i convenient as it looks like calling a regular
 function:
 
 .. code-block:: python
@@ -48,10 +48,9 @@ called `add`, returning the sum of two positional arguments:
 .. note::
 
     If the task is not registered in the current process
-    then you can also execute a task by name.
+    you can call it by name.
 
-    You do this by using the :meth:`@send_task` method of
-    the celery instance
+    The :meth:`@send_task` method is used for this purpose:
 
     .. code-block:: python
 
@@ -59,7 +58,7 @@ called `add`, returning the sum of two positional arguments:
         >>> result.get()
         4
 
-.. _executing-eta:
+.. _calling-eta:
 
 ETA and countdown
 =================
@@ -93,7 +92,7 @@ and timezone information):
     >>> tomorrow = datetime.now() + timedelta(days=1)
     >>> add.apply_async(args=[10, 10], eta=tomorrow)
 
-.. _executing-expiration:
+.. _calling-expiration:
 
 Expiration
 ==========
@@ -116,7 +115,7 @@ either as seconds after task publish, or a specific date and time using
 When a worker receives an expired task it will mark
 the task as :state:`REVOKED` (:exc:`~@TaskRevokedError`).
 
-.. _executing-serializers:
+.. _calling-serializers:
 
 Serializers
 ===========
@@ -195,7 +194,7 @@ to use when sending a task:
 
     >>> add.apply_async(args=[10, 10], serializer="json")
 
-.. _executing-connections:
+.. _calling-connections:
 
 Connections
 ===========
@@ -238,7 +237,7 @@ Though this particular example is much better expressed as a group:
     >>> res.get()
     [4, 8, 16, 32]
 
-.. _executing-routing:
+.. _calling-routing:
 
 Routing options
 ===============
@@ -303,7 +302,7 @@ by creating a new queue that binds to `"image.crop`".
 
     To find out more about routing, please see :ref:`guide-routing`.
 
-.. _executing-amq-opts:
+.. _calling-amq-opts:
 
 AMQP options
 ============

docs/userguide/groups.rst

@@ -71,7 +71,7 @@ If you have the subtask::
 
 ...
 
-Now let's execute our ``add`` task with a callback using partial
+Now let's call our ``add`` task with a callback using partial
 arguments::
 
     >>> add.apply_async((2, 2), link=add.subtask((8, )))

docs/userguide/index.rst

@@ -12,7 +12,7 @@
 
     overview
     tasks
-    executing
+    calling
     workers
     periodic-tasks
     groups

docs/userguide/overview.rst

@@ -31,7 +31,7 @@ The action to take whenever a message of a certain type is received is called
 a "task".
 
 * Go to :ref:`guide-tasks`.
-* Go to :ref:`guide-executing`.
+* Go to :ref:`guide-calling`.
 * Go to :ref:`guide-sets`
 * Go to :ref:`guide-beat`.
 * Go to :ref:`guide-webhooks`.

docs/userguide/remote-tasks.rst

@@ -90,18 +90,19 @@ or in Ruby on Rails:
 You can easily port this scheme to any language/framework;
 new examples and libraries are very welcome.
 
-.. _webhook-executing:
+.. _webhook-calling:
 
-Executing webhook tasks
-=======================
+Calling webhook tasks
+=====================
 
-To execute the task you use the :class:`URL` class:
+To call a task you can use the :class:`~celery.task.http.URL` class:
 
     >>> from celery.task.http import URL
     >>> res = URL("http://example.com/multiply").get_async(x=10, y=10)
 
 
-:class:`URL` is a shortcut to the :class:`HttpDispatchTask`. You can subclass this to extend the
+:class:`~celery.task.http.URL` is a shortcut to the :class:`HttpDispatchTask`.
+You can subclass this to extend the
 functionality.
 
     >>> from celery.task.http import HttpDispatchTask
@@ -116,7 +117,7 @@ task being executed::
             [f2cc8efc-2a14-40cd-85ad-f1c77c94beeb] processed: 100
 
 Since applying tasks can be done via HTTP using the
-:func:`djcelery.views.apply` view, executing tasks from other languages is easy.
+:func:`djcelery.views.apply` view, calling tasks from other languages is easy.
 For an example service exposing tasks via HTTP you should have a look at
 `examples/celery_http_gateway` in the Celery distribution:
 http://github.com/celery/celery/tree/master/examples/celery_http_gateway/

docs/userguide/routing.rst

@@ -197,7 +197,7 @@ A message consists of headers and a body.  Celery uses headers to store
 the content type of the message and its content encoding.  The
 content type is usually the serialization format used to serialize the
 message. The body contains the name of the task to execute, the
-task id (UUID), the arguments to execute it with and some additional
+task id (UUID), the arguments to apply it with and some additional
 metadata -- like the number of retries or an ETA.
 
 This is an example task message represented as a Python dictionary:

docs/userguide/tasks.rst

@@ -306,7 +306,7 @@ General
     serialization methods that have been registered with
     :mod:`kombu.serialization.registry`.
 
-    Please see :ref:`executing-serializers` for more information.
+    Please see :ref:`calling-serializers` for more information.
 
 .. attribute:: Task.backend