On Friday 17 October 2008 01:04:35 pm Rob Landley wrote:
> > Also, I don't understand the problem with poll potentially waiting
> > longer that specified under heavy load. If poll really waits longer, it
> > is more likely that additional data has arrived in this time, not less
> > likely.
>
> Yeah, as far as I can tell Denys is worrying about a problem that can't
> actually happen. The process scheduler won't delay the in-kernel response to
> new data arriving via a serial interrupt, so effectively all the scheduler
> could do is _extend_ the poll timeout by not scheduling the process promptly.
>
> Denys is making the delay longer because the scheduler might... _also_ make
> it longer. Seems a bit unnecessary, somehow.
Yep, I was confused there. Waiting too long is not a problem.
Waiting too little is.
What we discuss is
(a) how typical are scenarios where inter-character delay can
be big and unpredictable? Rob cleared my confusion
regarding receiving side (it generally can't enlarge delays
noticeably), sender side is more likely to create problems.
(b) how exact are really small waits (1-10ms) on really
slow hardware without high-res timers?
Anyway, 50ms even on slowest today's hardware ought
to be ok.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
