Date: Sun, 4 Jul 1999 15:09:27 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Jonathan Lemon <jlemon@americantv.com> Cc: hackers@freebsd.org, grog@freebie.lemis.com, peter@netplex.com.au Subject: Re: poll() scalability Message-ID: <Pine.BSF.4.10.9907041502290.54036-100000@salmon.nlsystems.com> In-Reply-To: <19990704085249.54969@right.PCS>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Jul 1999, Jonathan Lemon wrote: > On Jul 07, 1999 at 11:15:13AM +0100, Doug Rabson wrote: > > > In essence, I want to move the large "struct pollfd" array that I > > > have into the kernel, and then instruct the kernel to add/remove > > > entries from this array, and only return the array subset which > > > has activity. > > > > How does the kernel manage this? Does each process potentially store a > > struct pollfd in struct proc? This seems a bit limiting since it forces a > > program to have exactly one call to poll. > > Right now, the selection list is hung off of struct filedesc, since that > seemed a good place as any to put it. I'm not sure what you mean by > a 'single call' to poll; there can be multiple calls. The caller can > also call poll() or select() on a descriptor as well. What I mean is that since there is only set of new_poll information per filedesc (mostly the same as per-process), you can only have one piece of code in a program which calls new_poll. Imagine a routine in libc (or whatever) which could usefully use new_poll in its implication. To be able to work correctly when called form a program which is calling new_poll itself, the library routine would need to somehow read out the list of events the caller was using, replace it with its own list and then restore the caller's list later which defeats the object. I'm not arguing against the idea of new_poll but I just think it should scale to large and complex programs as well as large numbers of fds. > > > > Peter's description of David Filo's event queue thing seems to solve that > > problem by introducing a new kernel object (the event queue). > > Yes, it does seem more interesting, but I'd like to see more details. > If multiple processes are sharing the queue, then the queue registry > would have to be done at the struct file level, with something converting > the struct file pointer back into an fd, yes? I would like to see more details too. It sounds as if the implementation is at the struct file level. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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?Pine.BSF.4.10.9907041502290.54036-100000>