Re: pipes & ptys

[itschere@techfak.uni-bielefeld.de]

Juergen Lock
> 
> > Well, what else can I do in a Program like a window manager, if I've
> > got to look for every char?
> 
>  well Eric said that already but in different words... :)  a 1k RAW
> read() does not block until it has read 1k, only until _some_ data is
> available. (pty master reads are always RAW)  if it receives 200 bytes
> (i.e. pty slave write()s 200 bytes) it returns 200 bytes, if data comes
> in 1-byte-at-a-time it reads 1 byte, or whatever has accumulated in the
> buffer (pipe) since the last read.
> 
>  so look at each char does not mean you need one system call for each
> char...

Ok, got this, but: (see my other mail) it will return as soon as ther is
some data, say, when it get's its next time slice, which is 16ms long on
my 60Hz TT-VBL, right? Now I estimate that the writer (if really (worst case,
of course, but that's what counts.)) using 1 bytes I/O, doesn't manage
to output more than something like 30 chars per timeslice, so 60 slices
a 30 bytes (always completely ignoring the time I need to read the data),~
makes 1800 CPS, and that looks like the number I've measured.

> >   Point is that system calling overhead is soooo big that it doesn't matter
> > a lot if the pipefs has got to do 1 or 4 bytes read.
> 
>  yes but it doesn't... have to do single-char IO.  and when you have
> larger read/writes this character shuffling can cause overhead of
> n times the size of the actual device IO.

Perhaps we can start a personal dispute about this, but so far I heavily
doubt this. Sorry, no proofs so far... :-(

> type			read	write	speed (CPS)	% CPU load (top)
> -----------------------------------------------------------
> pipe			4096	4096	270000
> pty			4096	4096	a bit less
> 
>  pty output would get nearly as fast as the pipe, and serial ports could
> run full speed and no longer eat up all available cycles...

If a) you really use big chunks and b) modems are operated by interrupt...

> >  At least at my setup the involved device
> > drivers can easily be fixed.
> 
>  hmm how do you mean that?

Well, to make the biosfs drives expect char pointers instead longs. None
of my program _seems_ to complain about this. But obviously that's no
compatible solution... ;-)

[other stuff deleted, 'cause it's clear to me now]

bye,
TeSche