Hello,
Regarding your previous mail, we agree, except that I will implement the
"wait a little" thing. Believe me, after implementing the hardware part,
kernel programming is a breeze.
Nadav Har'El wrote:
The drawback of doing this
exactly like this, is that if data arrives at a slow rate (say, 100
kB/sec) it's likely that every read() operation will yield one byte of
data, making the CPU spin around this instead of doing something useful.
(...) Second, if the CPU *did* have "something useful" to do (run other
processes,
or whatever), it would, causing a bit more time to pass between the read()
and it might return more than one byte. It will only return one byte when
there's nothing better to do than calling read() all the time.
That's an interesting point, but I'm not 100% sure on that one. Why
would the scheduler take the CPU away, if the read() operation always
returns one byte or two? It would, eventually take it for a while, which
would let data stack up, but each process would get its fair slice.
I'm not saying this would cause some real degradation, but on a slow
embedded processor, seeing 10% CPU usage on a process which is supposed
to just read data...? The calculation is a 200 MHz processor, 100 kB/sec
and 200 CPU clocks for each byte being processed on itself.
--
Web: http://www.billauer.co.il
_______________________________________________
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
