Show More
@@ -397,16 +397,6 b' Message type: ``history_reply``::' | |||||
397 | 'output' : list, |
|
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 | Messages on the PUB/SUB socket |
|
401 | Messages on the PUB/SUB socket | |
412 | ============================== |
|
402 | ============================== | |
@@ -540,6 +530,35 b' Message type: ``input_reply``::' | |||||
540 | transported over the zmq connection), raw ``stdin`` isn't expected to be |
|
530 | transported over the zmq connection), raw ``stdin`` isn't expected to be | |
541 | available. |
|
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 | ToDo |
|
563 | ToDo | |
545 | ==== |
|
564 | ==== |
General Comments 0
You need to be logged in to leave comments.
Login now