X-Spam-Check-By: sourceware.org Message-ID: <44A3F101.2070400@netbauds.net> Date: Thu, 29 Jun 2006 16:25:53 +0100 From: Darryl Miles User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.0.4) Gecko/20060614 SeaMonkey/1.0.2 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Proposal: select(2) writability notifcation vs write operations on pipes References: <44A348D1 DOT 6070908 AT netbauds DOT net> In-Reply-To: <44A348D1.6070908@netbauds.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT 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 Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/