On Sun, 21 Jul 2002 17:54:59 -0700, Graham Nash wrote:
>I have also been seeing this scheduler error. I traced my problem down
>to the way select is handled. The select event remains in force until it
>is satisfied or the timeout expires. If during this period, one of the
>selectable file descriptors is closed, say, the select in
>pth_sched_eventmanager will fail (EBADFD) on the platform I am using.
>This has the result of looping around in pth_sched with the run queue
>empty, generating the observed failure. Your problem may be similar is
>nature. To remedy the problem, I rewrote a small amount of the user
>code. Clearly, is is possible to "fix" this in pth but there is more
>than one solution available and it is not clear which, if any, should be
>adopted.
This should be fixed in user space. The behavior when a socket is closed by
one thread while being used in another is undefined and it is impossible to
get sane results when you do this. There are *always* race conditions, and
this should *never* be done.
The problem is that another thread can never be sure that a thread is
actually in accept. It could always be about to call accept. If you close the
socket, and then another thread creates a socket, the socket descriptor you
closed may be reused. The first thread will then wind up selecting on the
wrong socket.
So you can literally never know what will happen when you do this. There is
no atomic 'accept and signal' or 'unlock and accept' operation. This will
always have undefined results.
DS
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
