Date: Tue, 6 Jul 1999 11:18:12 -0500 From: Jonathan Lemon <jlemon@americantv.com> To: Zach Brown <zab@zabbo.net> Cc: Niall Smart <niall@pobox.com>, Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: poll() scalability Message-ID: <19990706111812.31063@right.PCS> In-Reply-To: <Pine.LNX.4.10.9907061129440.5548-100000@hoser>; from Zach Brown on Jul 07, 1999 at 11:41:35AM -0400 References: <36E113A5.21F85DE5@pobox.com> <Pine.LNX.4.10.9907061129440.5548-100000@hoser>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 07, 1999 at 11:41:35AM -0400, Zach Brown wrote: > > Well, how about the kernel passes siginfo and siginfo_cancel events > > up to userland, siginfo will remove any siginfo's from its buffer > > that it sees a siginfo_cancel event for -- naturally we need a flag > > to tell siginfo when to poll for events, this flag would be > > set by the function which cancels siginfo's. Would this work? Is > > it worth the complexity? > > sure I imagine it would work, but I'd want to see someone come up for a > darn good reason to need it before bogging the system down with a mess > like that. I wouldn't want to post the events to userland; I think it would be better (and simpler) to handle the aggregation in the kernel. > at least in my case, some clever hoop-jumping gets rid of the nastiness of > having stale events.. keeping the kernel side as light weight as humanly > possible should be very high on the list of priorities here. Currently, I'm thinking along the lines of: 1. create an "event queue" 2. register your interest in various events with this queue. Note that it appears possible to get a little carried away here with specifying exactly what an event is. E.g.: only call it an event after > X bytes have arrived, or only after Y amount of time has passed with no activity, or some combination of the two. This would provide something like the reverse of a "delayed ack", on the receiver side. You could probably even register multiple timer events, and have an arbitrary number of timer events pending. :-) 3. a structure is allocated to handle the event at registration time, and hooked into the appropriate points in the kernel. 4. when an event occurs, instead of just tacking a new structure onto the queue, a kernel callback routine for the type of event specified in step 2 is performed. If it's determined that the event should be posted, the event structure is moved onto the "posted event" queue. If the event structure is already on this queue, no action is needed. 5. when the event is passed to userland, the stucture is dequeued. If the descriptor is closed (or interest unregistered), the structure is simply removed from the queue and deallocated. This should be fairly lightweight, as well as providing flexibility. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990706111812.31063>