On Wed, 3 Jan 2007, Brian Utterback wrote:
So, I am open to discussion on this. Is this a reasonable approach to
context switching between a producer and consumer, or should the
scheduler do this better? Perhaps instead of blocking, the process
should just lose the rest of its time slice? (I don't know if that is
feasible) Any thoughts on the subject?
The deadlock: Such apps are terminally buggy, surely? An app refusing to
read data indefinitely based on conditions of possible future data
should expect an indefinite lack of progress (no?).
Flow-control: I guess what's needed is to:
a) find a good dynamic buffer-sizing function
b) implement it so that both async and sync STREAMS avail of it.
For added goodness, abstract the dynamic-buffer-sizing function
interface such that TCP, TCP-fusion and STREAMS (etc) can use these
functions.
The trick is to find a good 'a' (See latest and greatest TCP window
algorithms, e.g. BIC and CUBIC).
Note: I don't think you can get what you want without having either time
or else a magic tunable as an input, as the problem is intrinsically
about rates. You need either to measure the actual rate or have the
sysadmin set some value that indicates "tune for this rate" (even if the
tunable is a value in some other dimension).
regards,
--
Paul Jakma,
Network Approachability, KISS. Sun Microsystems, Dublin, Ireland.
http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190
_______________________________________________
networking-discuss mailing list
[email protected]
