This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]