open.source/magic-wormhole
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7cc50e9701
magic-wormhole/docs/mailbox.dot

148 lines
7.1 KiB
Plaintext
Raw Normal View History

new approach, thinking about connections up front
2016-12-24 17:10:33 +00:00
digraph {
/* new idea */
more work, feels better now
2017-02-15 20:11:17 +00:00
{rank=same; M_title M_entry_whole_code M_entry_allocation M_entry_interactive}
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
M_entry_whole_code [label="whole\ncode"]
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_entry_whole_code -> M_S0A
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
M_title [label="Message\nMachine" style="dotted"]
more work, feels better now
2017-02-15 20:11:17 +00:00
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_entry_allocation [label="allocation" color="orange"]
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_entry_allocation -> M_S0B [label="already\nconnected" color="orange" fontcolor="orange"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_entry_interactive [label="interactive" color="orange"]
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_entry_interactive -> M_S0B [color="orange"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
{rank=same; M_S0A M_S0B}
M_S0A [label="S0A:\nknow nothing"]
M_S0B [label="S0B:\nknow nothing\n(bound)" color="orange"]
M_S0A -> M_S0B [label="M_connected()"]
M_S0B -> M_S0A [label="M_lost()"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_S0A -> M_S1A [label="M_set_nameplate()"]
M_S0B -> M_P2_claim [label="M_set_nameplate()" color="orange" fontcolor="orange"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
more work, feels better now
2017-02-15 20:11:17 +00:00
{rank=same; M_S1A M_P1A_queue}
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_S0B -> M_S2B [style="invis"]
M_S1A -> M_S2A [style="invis"]
M_S1A [label="S1A:\nnot claimed"]
M_S1A -> M_P2_claim [label="M_connected()"]
M_S1A -> M_P1A_queue [label="M_send(msg)" style="dotted"]
M_P1A_queue [shape="box" label="queue" style="dotted"]
M_P1A_queue -> M_S1A [style="dotted"]
{rank=same; M_S2B M_S2A M_P2_claim}
M_S2A [label="S2A:\nmaybe claimed"]
M_S2B [label="S2B:\nmaybe claimed\n(bound)" color="orange"]
more demo work
2017-02-14 07:12:57 +00:00
#M_S2B -> M_SrB [label="M_close()" style="dashed"]
#M_SrB [label="SrB" style="dashed"]
#M_S2A -> M_SrA [label="M_close()" style="dashed"]
#M_SrA [label="SrA" style="dashed"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_S2A -> M_P2_claim [label="M_connected()"]
more demo work
2017-02-14 07:12:57 +00:00
#M_S2B -> M_S2A [label="M_lost()"] # causes bad layout
M_S2B -> foo [label="M_lost()"]
foo [label="" style="dashed"]
foo -> M_S2A
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_P2_claim [shape="box" label="tx claim" color="orange"]
M_P2_claim -> M_S2B [color="orange"]
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_S2A -> M_P2C_queue [label="M_send(msg)" style="dotted"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_P2C_queue [shape="box" label="queue" style="dotted"]
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_P2C_queue -> M_S2A [style="dotted"]
more
2016-12-27 05:37:43 +00:00
M_S2B -> M_P2B_queue [label="M_send(msg)" style="dotted"]
M_P2B_queue [shape="box" label="queue" style="dotted"]
M_P2B_queue -> M_S2B [style="dotted"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_S1A -> M_S3A [label="(none)" style="invis"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S2B -> M_P_open [label="rx claimed" color="orange" fontcolor="orange"]
M_P_open [shape="box" label="store mailbox\ntx open\ntx add(queued)" color="orange"]
M_P_open -> M_S3B [color="orange"]
{rank=same; M_S3A M_S3B M_P3_open M_P3_send}
more work, feels better now
2017-02-15 20:11:17 +00:00
M_S3A [label="S3A:\nclaimed\nopened >=once"]
M_S3B [label="S3B:\nclaimed\nmaybe open now\n(bound)" color="orange"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S3A -> M_P3_open [label="M_connected()"]
M_S3B -> M_S3A [label="M_lost()"]
M_P3_open [shape="box" label="tx open\ntx add(queued)"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
M_P3_open -> M_S3B
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S3B -> M_S3B [label="rx claimed"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
M_S3B -> M_P3_send [label="M_send(msg)"]
M_P3_send [shape="box" label="queue\ntx add(msg)"]
M_P3_send -> M_S3B
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S3A -> M_P3_queue [label="M_send(msg)" style="dotted"]
more
2016-12-27 05:37:43 +00:00
M_P3_queue [shape="box" label="queue" style="dotted"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_P3_queue -> M_S3A [style="dotted"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S3A -> M_S4A [label="(none)" style="invis"]
M_S3B -> M_P3_process_ours [label="rx message(side=me)"]
more
2016-12-27 05:37:43 +00:00
M_P3_process_ours [shape="box" label="dequeue"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
M_P3_process_ours -> M_S3B
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S3B -> M_P3_process_theirs1 [label="rx message(side!=me)" color="orange" fontcolor="orange"]
M_P3_process_theirs1 [shape="box" label="tx release" color="orange"]
M_P3_process_theirs1 -> M_P3_process_theirs2 [color="orange"]
M_P3_process_theirs2 [shape="octagon" label="process message" color="orange"]
just might work. close() mapped out. Starting to draw a distinction between clean-close and abrupt-halt. At least, if we're in the connected state, wormhole.close() should take its time and free up server-side resources (nameplate/mailbox) right away, rather than relying on GC/timeouts to release them. It might be useful to make separate "clean" wormhole.close() and "abrupt" wormhole.halt() API calls, except that really when would you ever call halt? To be realistic, only one of two things will happen: * connection happens normally, app finishes, calls "clean" close() * app terminates suddenly, via exception or SIGINT The problem with defining .close() is that I have to make it work sensibly from any state, not just the one plausible "connected" state. Providing .halt() requires defining its behavior from everywhere else.
2016-12-27 06:32:01 +00:00
/* pay attention to the race here: this process_message() will
deliver msg_pake to the WormholeMachine, which will compute_key() and
more fussing, split out M_S0
2017-02-12 18:57:04 +00:00
M_send(version), and we're in between M_S1A (where M_send gets
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
queued) and M_S3A (where M_send gets sent and queued), and we're no
longer passing through the M_P3_open phase (which drains the queue).
So there's a real possibility of the outbound msg_version getting
just might work. close() mapped out. Starting to draw a distinction between clean-close and abrupt-halt. At least, if we're in the connected state, wormhole.close() should take its time and free up server-side resources (nameplate/mailbox) right away, rather than relying on GC/timeouts to release them. It might be useful to make separate "clean" wormhole.close() and "abrupt" wormhole.halt() API calls, except that really when would you ever call halt? To be realistic, only one of two things will happen: * connection happens normally, app finishes, calls "clean" close() * app terminates suddenly, via exception or SIGINT The problem with defining .close() is that I have to make it work sensibly from any state, not just the one plausible "connected" state. Providing .halt() requires defining its behavior from everywhere else.
2016-12-27 06:32:01 +00:00
dropped on the floor, or put in a queue but never delivered. */
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_P3_process_theirs2 -> M_S4B [color="orange"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
{rank=same; M_S4A M_P4_release M_S4B M_P4_process M_P4_send M_P4_queue}
more work, feels better now
2017-02-15 20:11:17 +00:00
M_S4A [label="S4A:\nmaybe released\nopened >=once\n"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
more work, feels better now
2017-02-15 20:11:17 +00:00
M_S4B [label="S4B:\nmaybe released\nmaybe open now\n(bound)" color="orange"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S4A -> M_P4_release [label="M_connected()"]
M_P4_release [shape="box" label="tx open\ntx add(queued)\ntx release"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
M_S4B -> M_P4_send [label="M_send(msg)"]
M_P4_send [shape="box" label="queue\ntx add(msg)"]
M_P4_send -> M_S4B
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S4A -> M_P4_queue [label="M_send(msg)" style="dotted"]
more
2016-12-27 05:37:43 +00:00
M_P4_queue [shape="box" label="queue" style="dotted"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_P4_queue -> M_S4A [style="dotted"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
M_P4_release -> M_S4B
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S4B -> M_S4A [label="M_lost()"]
M_S4B -> M_P4_process [label="rx message"]
M_P4_process [shape="octagon" label="process message"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
M_P4_process -> M_S4B
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S4A -> M_S5A [label="(none)" style="invis"]
M_S4B -> M_S5B [label="rx released" color="orange" fontcolor="orange"]
more
2016-12-24 17:18:06 +00:00
fixing 118 is the key
2016-12-25 14:38:46 +00:00
seed [label="from Seed?"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S3A -> seed [style="invis"]
M_S4A -> seed [style="invis"]
seed -> M_S5A
{rank=same; seed M_S5A M_S5B M_P5_open M_process}
more work, feels better now
2017-02-15 20:11:17 +00:00
M_S5A [label="S5A:\nreleased\nopened >=once"]
M_S5B [label="S5B:\nreleased\nmaybe open now\n(bound)" color="green"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S5A -> M_P5_open [label="M_connected()"]
M_P5_open [shape="box" label="tx open\ntx add(queued)"]
w2.dot: add M_ prefix
2016-12-26 18:45:03 +00:00
M_P5_open -> M_S5B
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_S5B -> M_S5A [label="M_lost()"]
M_S5B -> M_process [label="rx message" color="green" fontcolor="green"]
M_process [shape="octagon" label="process message" color="green"]
M_process -> M_S5B [color="green"]
M_S5B -> M_P5_send [label="M_send(msg)" color="green" fontcolor="green"]
M_P5_send [shape="box" label="queue\ntx add(msg)" color="green"]
M_P5_send -> M_S5B [color="green"]
M_S5A -> M_P5_queue [label="M_send(msg)" style="dotted"]
more
2016-12-27 05:37:43 +00:00
M_P5_queue [shape="box" label="queue" style="dotted"]
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_P5_queue -> M_S5A [style="dotted"]
M_S5B -> M_CcB_P_close [label="M_close()" style="dashed" color="orange" fontcolor="orange"]
M_CcB_P_close [label="tx close" style="dashed" color="orange"]
more
2016-12-27 05:37:43 +00:00
w3.dot: figure out close() pathways d=M_close() will always do the verbose clean shutdown thing, and the Deferred won't fire (e.g. we won't move to state "Ss") until we've deallocated our server resources (nameplates and mailboxes), and we've finished shutting down our websocket connection. So integration tests should wait on the Deferred to make sure everything has stopped moving and the reactor is clean. CLI applications that are following the success path can use M_close() and wait on the Deferred before terminating. CLI applications that wind up on some error path can either use M_close(), or just SIGINT and leave the server to GC stuff later. GUI applications can use M_close() but ignore the Deferred, and assume that the program will keep running long enough to get the deallocation messages through. GUI+DB applications can use M_close() and then stop recording state changes, and if the program remains running long enough, everything will be deallocated, but if it terminates too soon, the server will have to GC.
2016-12-28 04:23:35 +00:00
M_process [shape="octagon" label="process message"]
more
2016-12-27 05:37:43 +00:00
M_process_me [shape="box" label="dequeue"]
M_process -> M_process_me [label="side == me"]
M_process_them [shape="box" label="" style="dotted"]
M_process -> M_process_them [label="side != me"]
M_process_them -> M_process_pake [label="phase == pake"]
M_process_pake [shape="box" label="WM_rx_pake()"]
M_process_them -> M_process_other [label="phase in (version,numbered)"]
M_process_other [shape="box" label="WM_rx_msg()"]
new approach, thinking about connections up front
2016-12-24 17:10:33 +00:00
}
Reference in New Issue Copy Permalink