1
0
mirror of https://github.com/gryf/wmaker.git synced 2025-12-19 20:38:08 +01:00
Files
wmaker/WINGs/Documentation
dan f058fdf72c - Fixed small memory leak in the WINGs' font panel code.
- Fixed call to qsort in WMSortArray.
- Fixed a memleak in the WINGs' file panel.
2003-04-02 11:37:04 +00:00
..
.
2001-02-09 03:20:54 +00:00

Methods of handling WMConnectionDidDieNotification notification events
(same for WMConnectionDidTimeoutNotification)
----------------------------------------------------------------------

Once your program got this notification (you need to install an observer for 
it), there are some ways to handle it:

1. Make your observer enqueue a new notification in the ASAP queue, and the 
   observer for this new notification (it can be the same function if you 
   arrange to distinguish between the two cases), should remove the connection. 
   You can also close the connection before enqueuing the new notification to
   the ASAP queue, but is not strictly necessarily, since it will be closed 
   when the observer for the new enqueued notification will be called and you 
   will call the close/remove function there. This is just to make sure your 
   connection will be silent, and won't generate new events until you reach 
   that point.
   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 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.

4. Make you observer remove the connection. Then make sure that after that
   point your code no longer tries to access that connection (this usually
   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 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 
       WMGetMessage()/WMSendMessage()), not the C library ones read()/write().
Note2: removing a connection is done by WMDestroyConnection(), while
       WMCloseConnection() only closes the socket, and removed any pending
       queues and timers on the connection.