From:	cgf AT cygnus DOT com (Christopher G. Faylor)
Subject:	races in select code
8 Jun 1998 14:08:14 GMT :
Message-ID:	<6lgr8e$ltp$1@cronkite.cygnus.com>
X-Newsreader:	trn 4.0-test63 (15 March 1998)

While adding exception support to cygwin's dedicated threads (so I can
more easily track down SEGVs, etc.), I noticed that there are some race
conditions in the handling of sockets and pipes.  Specifically, a thread
is created which immediately waits for an event which may or may not
have been created in the main thread by the time the wait is performed.

The select code goes to some effort to preserve the pipe and socket threads
so that they can be reused the next time a select is done.  To accomplish
this, two events per thread are used.  These events are created after
the thread is created.  The obvious solution in this case is merely to
create the events prior to creating the thread.

However, the code could be greatly simplified if the threads themselves
were used as synchronization objects, i.e., select would take the
termination of a pipe or socket thread to mean that a pipe or a socket
is "selectable".  That would mean that up to four events would not be
necessary.

The downside to this is that it means that threads may be created each time
a select is called, rather than once, as happens now.  I don't notice any
obvious performance degradation with this method but I'd like to solicit
opinions on whether it "bad" to create threads in this context.  My feeling
is that since select is usually called to wait for an event that might
take some time, the thread creation overhead will not even be noticeable.
-- 
cgf AT cygnus DOT com             "Everything has a boolean value, if you stand
http://www.cygnus.com/      far enough away from it."  -- Galena Alyson Canada

- Raw text -