Darren Reed writes: > I imagine the trick might be to schedule a qtimeout() when the > timeout gets set and for the timeout handler to successively > reschedule itself.
It only needs to run as long as there's a non-zero amount of data in the buffer. I would schedule the timeout when the first message is added to the queue. If I get to the 64K boundary, then cancel the unexpired timer and forward the data along. If the timer goes off, then we must not yet have 64K worth of data, so just forward what we have. No need to reschedule; it'll happen implicitly when data are added to the queue. > When you say that the queue service procedure > will be enabled for the bulk putnext, what exactly is happening > here with respect to the timeout callback and the service > procedure? You can enable your own service procedure from the callback. > I mentioned select/poll because using these function calls from > applications is the usual way to handle devices like BPF in an > event driven application. Right ... but those are handled in the stream head, not in STREAMS modules or drivers. Unless you're implementing a sync STREAMS interface (see the current implementation of UDP in Nevada), you don't have control over them. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
