Show More
@@ -397,16 +397,6 b' Message type: ``history_reply``::' | |||
|
397 | 397 | 'output' : list, |
|
398 | 398 | } |
|
399 | 399 | |
|
400 | ||
|
401 | Control | |
|
402 | ------- | |
|
403 | ||
|
404 | Message type: ``heartbeat``:: | |
|
405 | ||
|
406 | content = { | |
|
407 | # FIXME - unfinished | |
|
408 | } | |
|
409 | ||
|
410 | 400 | |
|
411 | 401 | Messages on the PUB/SUB socket |
|
412 | 402 | ============================== |
@@ -540,6 +530,35 b' Message type: ``input_reply``::' | |||
|
540 | 530 | transported over the zmq connection), raw ``stdin`` isn't expected to be |
|
541 | 531 | available. |
|
542 | 532 | |
|
533 | ||
|
534 | Heartbeat for kernels | |
|
535 | ===================== | |
|
536 | ||
|
537 | Initially we had considered using messages like those above over ZMQ for a | |
|
538 | kernel 'heartbeat' (a way to detect quickly and reliably whether a kernel is | |
|
539 | alive at all, even if it may be busy executing user code). But this has the | |
|
540 | problem that if the kernel is locked inside extension code, it wouldn't execute | |
|
541 | the python heartbeat code. But it turns out that we can implement a basic | |
|
542 | heartbeat with pure ZMQ, without using any Python messaging at all. | |
|
543 | ||
|
544 | The monitor sends out a single zmq message (right now, it is a str of the | |
|
545 | monitor's lifetime in seconds), and gets the same message right back, prefixed | |
|
546 | with the zmq identity of the XREQ socket in the heartbeat process. This can be | |
|
547 | a uuid, or even a full message, but there doesn't seem to be a need for packing | |
|
548 | up a message when the sender and receiver are the exact same Python object. | |
|
549 | ||
|
550 | The model is this:: | |
|
551 | ||
|
552 | monitor.send(str(self.lifetime)) # '1.2345678910' | |
|
553 | ||
|
554 | and the monitor receives some number of messages of the form:: | |
|
555 | ||
|
556 | ['uuid-abcd-dead-beef', '1.2345678910'] | |
|
557 | ||
|
558 | where the first part is the zmq.IDENTITY of the heart's XREQ on the engine, and | |
|
559 | the rest is the message sent by the monitor. No Python code ever has any | |
|
560 | access to the message between the monitor's send, and the monitor's recv. | |
|
561 | ||
|
543 | 562 | |
|
544 | 563 | ToDo |
|
545 | 564 | ==== |
General Comments 0
You need to be logged in to leave comments.
Login now