[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pipes & ptys
> Howard Chu <email@example.com> 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. :-)
J"urgen Lock / firstname.lastname@example.org / UUCP: ..!uunet!unido!uniol!jelal!nox
PGP public key fingerprint = 8A 18 58 54 03 7B FC 12 1F 8B 63 C7 19 27 CF DA