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 Date: Tue, 10 Dec 2002 23:12:51 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Cc: tom AT huno DOT net Subject: pipe improvements in snapshot Message-ID: <20021211041250.GA31215@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com, tom AT huno DOT net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i In the most recent cygwin snapshot (uploading now) I've attempted to work around the 10ms delay in pipe reads. I've managed this by resurrecting an idea I had back in 1998, updated for the new millenium. My idea was shot down by other (then) Cygnus employees but since they are now gone and I'm in charge of the project it seems like a good idea to dust it off and try again. In a nutshell, what cygwin now does is start pipe reads in another thread. If a signal arrives, the thread (and the read) is terminated. Depending on how Windows is implemented, it's *possible* that there will be data loss in this scenario. It would be very very hard to to prove that is the case, however. Please check out the latest snapshot and report here if there are problems. I haven't yet tried this on Windows 9x class systems so it's entirely possible that there is a problem there. If this looks good, I will probably release a cygwin 1.3.18 fairly soon. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/