[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pipes & ptys
> > 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
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]