Changes between Initial Version and Version 1 of Ticket #1768, comment 3


Ignore:
Timestamp:
2013-07-03T16:53:55Z (11 years ago)
Author:
zooko
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1768, comment 3

    initial v1  
    99This reminds me of #653, in which we determined that most likely there is a bug in foolscap which causes {{{notifyOnDisconnect}}} to ''not'' get called sometimes when it should get called. Putting these two together, it makes me think that foolscap can currently err on both sides — double-invoking a "respond to disconnect" event sometimes (but we've seen this only on Windows) and zero-invoking it other times.
    1010
    11 As I've mentioned before, I really think "responding to disconnect events" is a losing game. To me it smells deal like "clean shutdown logic" in an app. It tends to be buggy, it is labor-intensive to implement and debug it, and it can never be 100% correct (because shutdowns of an app are sometimes hard and because disconnections of a network are sometimes undetectable).
     11As I've mentioned before, I really think "responding to disconnect events" is a losing game. To me it smells like "clean shutdown logic" in an app. It tends to be buggy, it is labor-intensive to implement and debug it, and it can never be 100% correct (because shutdowns of an app are sometimes hard and because disconnections of a network are sometimes undetectable).
    1212
    1313So my preference for "crash-only programming" in which you don't expend engineering effort trying to design and implement for handling the "clean shutdown" case is perhaps related to my preference for "crash-only networking", in which you assume that your application won't get a reliable notification of disconnect, and you don't expend engineering effort trying to deliver one.