Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Jul 1999 08:52:49 -0500
From:      Jonathan Lemon <jlemon@americantv.com>
To:        Doug Rabson <dfr@nlsystems.com>
Cc:        hackers@freebsd.org, grog@freebie.lemis.com, peter@netplex.com.au
Subject:   Re: poll() scalability
Message-ID:  <19990704085249.54969@right.PCS>
In-Reply-To: <Pine.BSF.4.10.9907041107490.15087-100000@salmon.nlsystems.com>; from Doug Rabson on Jul 07, 1999 at 11:15:13AM %2B0100
References:  <19990704000042.59954@right.PCS> <Pine.BSF.4.10.9907041107490.15087-100000@salmon.nlsystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990704085249.54969>