Show More
@@ -30,7 +30,7 b' large blocking requests or database actions in the Hub do not have the ability t' | |||||
30 | job submission and results. |
|
30 | job submission and results. | |
31 |
|
31 | |||
32 | Registration (``ROUTER``) |
|
32 | Registration (``ROUTER``) | |
33 | *********************** |
|
33 | ************************* | |
34 |
|
34 | |||
35 | The first function of the Hub is to facilitate and monitor connections of clients |
|
35 | The first function of the Hub is to facilitate and monitor connections of clients | |
36 | and engines. Both client and engine registration are handled by the same socket, so only |
|
36 | and engines. Both client and engine registration are handled by the same socket, so only | |
@@ -111,7 +111,7 b' Message type : ``unregistration_notification``::' | |||||
111 |
|
111 | |||
112 |
|
112 | |||
113 | Client Queries (``ROUTER``) |
|
113 | Client Queries (``ROUTER``) | |
114 | ************************* |
|
114 | *************************** | |
115 |
|
115 | |||
116 | The hub monitors and logs all queue traffic, so that clients can retrieve past |
|
116 | The hub monitors and logs all queue traffic, so that clients can retrieve past | |
117 | results or monitor pending tasks. This information may reside in-memory on the Hub, or |
|
117 | results or monitor pending tasks. This information may reside in-memory on the Hub, or | |
@@ -242,8 +242,8 b' Message type: ``task_destination``::' | |||||
242 | 'engine_id' : '1234-abcd-...', # the destination engine's zmq.IDENTITY |
|
242 | 'engine_id' : '1234-abcd-...', # the destination engine's zmq.IDENTITY | |
243 | } |
|
243 | } | |
244 |
|
244 | |||
245 | :func:`apply` and :func:`apply_bound` |
|
245 | :func:`apply` | |
246 | ************************************* |
|
246 | ************* | |
247 |
|
247 | |||
248 | In terms of message classes, the MUX scheduler and Task scheduler relay the exact same |
|
248 | In terms of message classes, the MUX scheduler and Task scheduler relay the exact same | |
249 | message types. Their only difference lies in how the destination is selected. |
|
249 | message types. Their only difference lies in how the destination is selected. | |
@@ -260,18 +260,17 b' code string, must be able to send arbitrary (pickleable) Python objects. And ide' | |||||
260 | as little data as we can. The `buffers` property of a Message was introduced for this |
|
260 | as little data as we can. The `buffers` property of a Message was introduced for this | |
261 | purpose. |
|
261 | purpose. | |
262 |
|
262 | |||
263 |
Utility method :func:`build_apply_message` in :mod:`IPython.zmq.s |
|
263 | Utility method :func:`build_apply_message` in :mod:`IPython.zmq.serialize` wraps a | |
264 | function signature and builds a sendable buffer format for minimal data copying (exactly |
|
264 | function signature and builds a sendable buffer format for minimal data copying (exactly | |
265 | zero copies of numpy array data or buffers or large strings). |
|
265 | zero copies of numpy array data or buffers or large strings). | |
266 |
|
266 | |||
267 | Message type: ``apply_request``:: |
|
267 | Message type: ``apply_request``:: | |
268 |
|
268 | |||
269 |
|
|
269 | metadata = { | |
270 | 'bound' : True, # whether to execute in the engine's namespace or unbound |
|
|||
271 | 'after' : ['msg_id',...], # list of msg_ids or output of Dependency.as_dict() |
|
270 | 'after' : ['msg_id',...], # list of msg_ids or output of Dependency.as_dict() | |
272 | 'follow' : ['msg_id',...], # list of msg_ids or output of Dependency.as_dict() |
|
271 | 'follow' : ['msg_id',...], # list of msg_ids or output of Dependency.as_dict() | |
273 |
|
||||
274 | } |
|
272 | } | |
|
273 | content = {} | |||
275 | buffers = ['...'] # at least 3 in length |
|
274 | buffers = ['...'] # at least 3 in length | |
276 | # as built by build_apply_message(f,args,kwargs) |
|
275 | # as built by build_apply_message(f,args,kwargs) | |
277 |
|
276 | |||
@@ -360,8 +359,8 b' Split Sends' | |||||
360 | Previously, messages were bundled as a single json object and one call to |
|
359 | Previously, messages were bundled as a single json object and one call to | |
361 | :func:`socket.send_json`. Since the hub inspects all messages, and doesn't need to |
|
360 | :func:`socket.send_json`. Since the hub inspects all messages, and doesn't need to | |
362 | see the content of the messages, which can be large, messages are now serialized and sent in |
|
361 | see the content of the messages, which can be large, messages are now serialized and sent in | |
363 |
pieces. All messages are sent in at least |
|
362 | pieces. All messages are sent in at least 4 parts: the header, the parent header, the metadata and the content. | |
364 |
|
|
363 | This allows the controller to unpack and inspect the (always small) header, | |
365 | without spending time unpacking the content unless the message is bound for the |
|
364 | without spending time unpacking the content unless the message is bound for the | |
366 | controller. Buffers are added on to the end of the message, and can be any objects that |
|
365 | controller. Buffers are added on to the end of the message, and can be any objects that | |
367 | present the buffer interface. |
|
366 | present the buffer interface. |
General Comments 0
You need to be logged in to leave comments.
Login now