This is the mail archive of the
mailing list for the Cygwin project.
Proposal: select(2) writability notifcation vs write operations on pipes
- From: Darryl Miles <darryl-mailinglists at netbauds dot net>
- To: cygwin at cygwin dot com
- Date: Thu, 29 Jun 2006 16:25:53 +0100
- Subject: Proposal: select(2) writability notifcation vs write operations on pipes
- References: <44A348D1.email@example.com>
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