From owner-freebsd-hackers Sun Jul 4 6:53: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 094F914C36 for ; Sun, 4 Jul 1999 06:53:01 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id IAA29060; Sun, 4 Jul 1999 08:52:50 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id IAA09801; Sun, 4 Jul 1999 08:52:49 -0500 Message-ID: <19990704085249.54969@right.PCS> Date: Sun, 4 Jul 1999 08:52:49 -0500 From: Jonathan Lemon To: Doug Rabson Cc: hackers@freebsd.org, grog@freebie.lemis.com, peter@netplex.com.au Subject: Re: poll() scalability References: <19990704000042.59954@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Doug Rabson on Jul 07, 1999 at 11:15:13AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. > 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? > > struct fd_change { > > short fd; > > short events; > > }; > > Limited to 32767 file descriptors. Trivial to change though. Do you remove > a fd from the list by setting events to 0? Actually, by setting events to "DELETE"; then the descriptor is removed from the kernel's internal list. > As I said before I'm uneasy about the kernel tracking the state (list of > fds) in the process. A separate kernel object would be a much cleaner > solution and would be usable by a program which called poll in many > different ways. > > With this api, a library would be unable to use the new interface since it > would not know the new_poll state setup by the main program and would not > be able to change it without potentially breaking the caller's state. I'm not sure how a library would fit in. The main program will have to keep some state, which wouldn't be available to the library either. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message