Re: pipes & ptys

[Juergen Lock <nox@jelal.north.de>]

itschere@TechFak.Uni-Bielefeld.DE writes:
> Howard Chu <hyc@hanauma.jpl.nasa.gov> writes:
> 
> > A simple shell would just use cooked mode and read a line at a time, not
> > single-character, btw...
> 
> Maybe the shell, but not my imaginary window manager. If it waits for each
> newline, screen output will look pretty poor... :-(
> 
> > Just a note to TeSche - the 1 byte I/Os are converted to 4 bytes to allow
> > pty's to pass scan code and shift status info, just like Bconin from console.
> 
> Looking at the code, I discovered that recently. Point is that it - more or
> less - doesn't matter if my 1000 1 byte fread calls get expanded to 100 4 bytes
> fread calls. It looks like waiting with fselect(m,0,0,0) (thanks Eric!) and
> than read all that is there with one fread call is the best idea at the
> moment. I'll look at it, but for now I presume finstat() really reports the
> number of bytes in a pipe.

 yes but you don't need it, since the read() is RAW it will tell you how
much data it got.

>  So at least my reading program will not be the
> bottleneck, if the writing one choses to write in 1 byte chunks, I loose...

 not you if you usleep (or Fselect(m,0,0,0)) before the read...

>  ... So you won't need an extra system call, but just a new device
> driver for the biosfs...

 hmm looks i was not clear enough again :)  that was exactly my point 4...
> 
> Perhaps I'll start playing with this idea in some future, it's just that I
> expect great difficulties with existing programs, since they MUSTN'T use the
> bcon*() calls any more... :-(

 well if you dup2() the new device to the programs' /dev/aux...  but
since Bcon* still is single-char IO programs that use it will still
be big CPU time eaters so you might want to get rid of them anyway. :-)
> 
> bye,
> TeSche
 cheers
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA