From 40386e1d4031e2c479a840f6a907df6eb16f13d3 Mon Sep 17 00:00:00 2001 From: dan Date: Fri, 9 Feb 2001 03:20:54 +0000 Subject: [PATCH] . --- WINGs/Documentation/README.connection | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/WINGs/Documentation/README.connection b/WINGs/Documentation/README.connection index 1176782b..be4c200b 100644 --- a/WINGs/Documentation/README.connection +++ b/WINGs/Documentation/README.connection @@ -17,13 +17,16 @@ it), there are some ways to handle it: This is by far the best method, since it will assure you that if you enqueue more than one notification to remove the same connection, they will be coalesced, and called only once. -2. In your observer, put the died/closed connection in a bag, and destroy all - the connections present in the bag, in your main loop, after you call the - WHandleEvents()/WMHandleEvent(). Also closing the connection can be done - before putting the connection in the bag, but is optional as noted above. - In this case you need to make sure you don't put in the bag the same - connection more than once, in case the DieNotification is sent more that - once to you. This is automagically solved by method 1. + +2. In your observer, put the died/closed connection in an array or bag, and + destroy all the connections present in the array/bag, in your main loop, + after you call the WHandleEvents()/WMHandleEvent(). Also closing the + connection can be done before putting the connection in the array/bag, but + is optional as noted above. In this case you need to make sure you don't + put in the array/bag the same connection more than once, in case the + DieNotification is sent more that once to you. This is automagically solved + by method 1. + 3. In case it's your only connection, and you plan to exit if it was closed or died, then you can safely close/remove it, and exit. As long as you no longer access it, there is no problem. @@ -33,10 +36,11 @@ it), there are some ways to handle it: means until your code gets back to the main loop). This is almost always very hard to achive and subject to hidden errors. I do not recommend this way of handling the died notification. It is ugly and very complicated to - handle. If you use it and get plenty of SIGSEGVs then you know why. - This method was not presented here to be used, but to show what should - be avoided in dealing with the died notification, in case someone gets the - idea to try it this way. + handle if the program is in a very deeply nested function when it finds out + that the connection died. If you use it and get plenty of SIGSEGVs then you + know why. This method was not presented here to be used, but to show what + should be avoided in dealing with the died notification, in case someone + gets the idea to try it this way. Note: read/write operations means to use our read/write functions (like -- 2.11.4.GIT