Date: Sun, 4 Jul 1999 17:51:04 +0200 (CEST) From: Remy Nonnenmacher <remy@synx.com> To: dfr@nlsystems.com Cc: hackers@FreeBSD.ORG Subject: Re: poll() scalability Message-ID: <199907041551.RAA05530@rt2.synx.com> In-Reply-To: <Pine.BSF.4.10.9907041502290.54036-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Jul, Doug Rabson wrote:
> 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.
>
IMHO, having only one poll central point is quiet common. From my POV,
based on my needs, the calls I would like to see are :
- old_flags = poll_conditions(fd, READ|WRITE) ;
- poll_reset() ;
- fd = poll_next(&fd, &condition_returned, &timeout)
- len = poll_read(&fd, &buffer, len, &timeout);
- len = poll_write(fd, &buffer, len);
with the behaviors:
- closing an fd cancels participation in the poll round.
- fork() and vfork() keeps the polls flags. in this case, poll_reset()
allows for resetting all poll flags() on any fd.
- rfork() allows for sharing flags (and rounding) between processes.
- poll_next() will give the next fd next to the one previously returned
(or the next to the one based on its input value, using NULLs as "don't
care") restarting at lower flagged fd when last one reached.
- poll_read() being equivalent to {poll_next() ; read()}.
- poll_write() being able to automatically have WRITE polling flags
turned on if write fails, and off if it succeeds.
I agree that the last poll_write() stuff is questionable and is just
there for regularity. I also recognize that introduces new calls that
can be implemented using standard ones is also questionable. Anyway, my
main use would be the poll_read() stuff.
Implementation would be easy in the filedesc, using :
char *fd_pollflags : same usage as fd_ofileflags
u_short fd_firstpolled ; lowest polled fd
u_short fd_lastpolled ; highest polled fd
u_short fd_currentpolled ; current polled fd (to base next one)
also, fd_ofileflags could be extended to store the polling flags instead
of creating a new table.
RN.
IhM
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?199907041551.RAA05530>