Proposal: select(2) writability notifcation vs write operations on pipes

[Darryl Miles <darryl-mailinglists at netbauds dot net>]

Further to my recent follow up to the:  rsync over ssh hang issue understood



Having thought about the problem with select(2) writability to pipes 
that cygwin is emulating.  I'd like to propose the following:

* That all writing operations to pipes are checked to see if there is 
already an active writer thread for that fd.  If there is the call to 
write() we are currently emulating blocks (from the point of view of the 
POSIX app).  Since that is exactly what would happen under unix and this 
guarantees write orders are correct.  We become unblocked when the 
writer thread completes its operation.

* That all writing to WIN32 NamedPipes is done non-blocking version of 
WriteFileEx() call.  If the response back from the WIN32 kernel is that 
it can't take the data yet (would have blocked) then the following plan 
jumps into action:

* We try to pickup an idle I/O thread (thats already created and in idle 
state right now).  If we can't pickup an idle thread because they are 
all busy or there are none we create a new thread.

* We pass our current write data (by way of a private copy) to the 
thread and tell the thread to run the IO.

* The writer thread will now perform the I/O and it will use blocking 
WriteFileEx() call to do it.

* The write(2) operation we were just running may now return control 
back to the caller.


* A writer thread completes its operation, then put itself in an idle 
thread list and goes to sleep for a small amount of time (3 or 5 
seconds, dynamic timeout???).  If no new work comes in within that time 
the writer thread wakes up again and removes itself from the idle list 
and the thread terminates.  So its self cleaning.

* The select(2) writability bit for an fd is not considered set unless 
there is no active writer thread on that fd.  The select(2) will need to 
wakeup from timeout if a writer thread completes I/O on an fd where we 
are waiting for writability from it.


The above would mean that most write(2) operations would not involve a 
writer thread and would work just as now.  Its only after the first 
indication from WriteFileEx() that we would have blocked do we start 
using a writer thread to offload that problematic blocking call.


Can anyone see a flaw with implementing it concept in this way.

Request for comments,

Darryl L. Miles

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/