Re: [Quickfix-developers] Acceptor cleanup problem when port is busy (QuickFIX 1.3.2)
Brought to you by:
orenmnero
From: <OM...@th...> - 2003-01-28 18:38:25
|
Actually we can probably handle the onRun situation. Right now QF first starts the onRun thread, then does the initialization. I think this is backwards. It should first initialize (create all the sessions, files, sockets, blah blah), and only then start the onRun thread if everything is succesful. That way in this situation we can throw an exception like we do for everything else. In this case the developer doesn't need to clean up onRun since it never actually started. --oren |---------+-----------------------------------------------> | | Gene Gorokhovsky | | | <mus...@ya...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 01/28/2003 12:03 PM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: qui...@li... | | cc: | | Subject: [Quickfix-developers] Acceptor cleanup problem when port is busy (QuickFIX | | 1.3.2) | >----------------------------------------------------------------------------------------------| Quickfix 1.3.2 has a following problem: when the port specified for acceptor is already taken (for example FIX server is started erroneously twice), acceptor fails, but gives no indication to of that to the host program. Acceptor (both ST and MT) "start" method still returns true as if application has shut down normally, and no Application method is called to indicate that something is wrong. Since thread that executes Application->onRun does not exit on user action (as is normally the case), and no indication is given to program that something is wrong, this behavior usually results in an unpleasant situtaion such as deadlock (when thread_join is attempted with never-exiting onRun), or a crash (on my Linux due to a libpthread bug thread_join returns fine, but onRun is still executing and crashes when application class is cleaned up) Although there is nothing that FIX engine can do to stop onRun thread by itself, it should somehow indicate to the host program that the acceptor failed to initiate the accepting socket. Returning "false" from the start method would allow the developers to clean up onRun themselves. Fixing return value of the start method will require small modifications to SocketAccepor::onStart, and ThreadedSocketAcceptor::onStart; if the blocking call (SocketServer->block or socket_accept) fails, the whole method should return false. Gene __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |