Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Message-ID: <01cc01c24d10$f3b499b0$6132bc3e@BABEL> From: "Conrad Scott" To: References: <00c501c2496e$39ae2720$6132bc3e AT BABEL> <1029976536 DOT 27825 DOT 46 DOT camel AT lifelesswks> <025401c24a0d$1c996380$6132bc3e AT BABEL> <1030060087 DOT 8462 DOT 14 DOT camel AT lifelesswks> <20020824191035 DOT GB27153 AT redhat DOT com> <018201c24d0b$aa2d26e0$6132bc3e AT BABEL> <20020826162921 DOT M5475 AT cygbert DOT vinschen DOT de> Subject: Re: readv/writev Date: Mon, 26 Aug 2002 15:57:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 "Corinna Vinschen" wrote: > > On Mon, Aug 26, 2002 at 03:20:00PM +0100, Conrad Scott wrote: > > > > At the coal-face it ends up being a bit more messy than that. For > > example, the fhandler::read code checks the readahead buffers for > > pending data but they will always be empty in binary-mode (AFAIK) > > . In fact there's a page of code before the check for whether a > > binary read is being done and only then does the code escape back > > to the caller. Since (AFAIK) you can't change the text/binary > > mode of an fd once it's been opened (and thus the readahead > > You can. setmode(fd, O_TEXT); or setmode(fd, O_BINARY); Sorry: I'd missed that in my meanderings about the source. Thanks for the pointer. And as for my comments about the readahead buffer in text-mode handling: well, I was only thinking about "fast" devices; you couldn't just flush the readahead in general. Even if the text-mode support were removed from fhandler_serial, as Chris suggested, there're still pipes to worry about. So, I'll go and worry about something else instead :-) // Conrad