On Sat, Jan 26, 2002 at 03:42:22PM -0500, Allen Smith wrote: > On Jan 22, 2:11am, Joshua N Pritikin wrote: > > On Tue, Jan 22, 2002 at 01:54:50AM -0500, Allen Smith wrote: > > > OK, except that I thought that async prio was -1, not 5? > > > > i'm talking about async watchers not async priority. > > In other words, for one_loop, if the priority of an asynchronous event > is 5 or less, it will be queued before finding out if there are any > non-async events available. If it is above, it will only be queued > after finding out if there are any non-async events available. > > Hmm... it seems to make more sense to do things as follows: > > 1. Queue asyncronous events (signals, etc). > 2. If there are any events with priority 5 or less (see StarvePrio), > and there are non-async, non-timeout possible events with a > priority equal to or less than the lowest async event priority, do > poll/select with a 0 timeout. Upon return, queue all pending > events, and service the lowest-priority event (with priority 5 or > less), then return. > 3. Calculate the maximum wait time (minimum time till the next timer > expiration) and pass control to the poll/select system call. Upon > return, queue all pending events. > 4. Queue asyncronous events again. > 5. If there are any events then service the next one and return. > 6. Service the next idle watcher.
Yes, that sounds correct. It's really fairly insignificant because there should never be so many events happening that starvation actually happens. i suppose that "StarvePrio" is an exciting name so everyone wants to know what it does, but actually it's not very exciting. ;-) -- Victory to the Divine Mother!! after all, http://sahajayoga.org http://why-compete.org
