On Mon, 2008-04-21 at 23:45 +1200, Amos Jeffries wrote: > >> IMO, The proposed API _very_ first two lines of code in comm_close are to > >> register a special Comm callback to perform the fclose() call, and then to > >> immediately set fd_table flag closed for the rest of the comm_close > >> process. > > > > Agreed on the flag, disagreed on the call. The special/internal Comm > > call (to self) should be scheduled last (after all close callbacks) and > > not first because the close handler might need access to some FD-related > > info. That info should be preserved until all close handlers have been > > called. > > > >> With that condition at the start we can guarantee that any registrations > >> made during the close sequence are either non-FD-relevant or caught. > > > > Yes, the flag is sufficient for that. The internal "close for good" call > > can still be last. > > I was thinking the close-for-good call would get caught as an fd > operation on closed fd by the Async stuff if set after the flag.
Actually, the internal close-for-good call handler asserts that the flag is set! This internal handler does not have the structure or the restrictions of the public comm_* functions... > >> The special Comm callback is only special in that it is not required to > >> check flags open before fclose()'ing the system-level FD, which will allow > >> new connections to open on the FD. > > > > It is special because it is calling an internal comm method not some > > external close handler. Its profile and parameters are different. I > > would not call it a callback because of that, but the label is not > > important. It is not a close callback in terms of > > comm_add_close_handler. > > Yet it seems to me it needs to be run as an async after the other async > close-handlers are run. Due to the non-determinence of the async timing. Yes, the it must called asynchronously. The call is scheduled after all close callbacks are scheduled so that it will be dialed last. Alex.