Hi Wim, you are totally right.
If I keep the thread alive for a few seconds, I can connect to the server, and it keeps responding also after the initial thread exits. During this time, it shows as "starting" in the service control manager and can not be stopped therefore. I can also create new sessions from other clients after the initial thread exit. But here comes the catch: If I don't do the initial connection while I'm holding back the thread, I can not connect anymore, and the behavior is as before. So, should I create a dummy connection from the starting thread before exiting? Rgds Richard On Tue, 2009-06-09 at 20:59 +0200, Wim Dumon wrote: > Hmm, I wonder if this could be a case where windows associates things > with threads that should not be associated with threads. Does the > thread that starts the server exit during the procedure of launching > the service? If so, could you prevent it from doing so (add while(1) > sleep(1000);)? I don't consider it impossible that an asynchronous > operation (in this case: accept) in windows is aborted when the thread > that initiated the asynchronous operation exits. > > 2009/6/9 Richard Ulrich <[email protected]>: > > Hi Wim, > > > > Server::handleTcpAccept() is indeed called with an error. > > The error is : "system:995" > > Which according to the internet is most likely : "The I/O operation has > > been aborted because of either a thread exit or an application request." > > > > In the commandline version, when I hit Ctrl-C, Server::handleTcpAccept() > > is also called with the 995 error. > > > > Also I added a message to Server::handleStop() which I don't see in the > > log files (neither commandline nor service). > > > > Rgds > > Richard > > > > > > On Sun, 2009-06-07 at 21:59 +0200, Wim Dumon wrote: > >> Richard, > >> > >> there is only one reason that I can think of why the threads are > >> exiting, and that is that asio believes that there is no more work to > >> do. Just after starting, the only task that is queued in asio is an > >> asynchronous accept. Right now, I don't see how port 8080 can be in > >> the LISTENING state while the accept call fails. > >> > >> Could you: > >> - Verify if Server::handleTcpAccept() in Server.C is called with an error > >> - check what this error is (if I'm not mistaken you can simply use > >> operator<< to cat it into a std::stream) > >> > >> Bye, > >> Wim. > > > > > > > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
