- From: Kenneth Haase <kh@beingmeta.com>
- Date: Tue, 8 Jan 2002 08:58:45 -0500
- To: www-lib@w3.org
- Cc: kh@beingmeta.com
- Message-Id: <200201081715.g08HFMc22018@server1.beingmeta.com>
Perhaps I'm using it wrong, but I have a problem where the select loop in HTEventList_loop hangs. I am trying to use libwww, with its pseudo threads, from an external application which is actually threaded. My approach is to run the libwww event loop in its own single thread; other threads create requests and then block until the libwww loop has finished processing it. (I handle the locking with AFTER methods on the requests). The problem is that when I start the loop, it enters a call to select with no file descriptors and no timeouts. I then create a request which goes to the point where it need to get the actual connection; this can't happen right away, so the call just posts an event waiting for the socket to get its connection and continues. However, because select is in its forever loop, it doesn't note that there is a new socket to be watched and the successful connection --- when it comes from the remote server --- is never recognized. The fix I've come up with, appended below, is to replace the "never timeout" default case with a "look around every second" case. Another approach, I suppose, would be to send a signal to the www thread, which will cause select to exit, but this seems messy and pretty non-portable. Please let me know if this gets added to the official version, as I want to release the code which relies on it. Alternatively, if there is a better way to get this same effect (adding a request after the main loop has been started from outside of the main loop), I would be delighted to hear about it. Cheers, Ken
Attachments
- text/x-diff attachment: Fix to libwww HTEventList_loop
Received on Tuesday, 8 January 2002 09:00:30 UTC