Date: Sun, 17 Jun 2001 14:23:20 +0200 (MEST) From: Sascha Schumann <sascha@schumann.cx> To: Valentin Nechayev <netch@iv.nn.kiev.ua> Cc: <freebsd-hackers@FreeBSD.ORG> Subject: Re: poll(2)'s arbitrary limit Message-ID: <Pine.LNX.4.33.0106171356230.4306-100000@rossini.schumann.cx> In-Reply-To: <20010617123008.A585@iv.nn.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> sys/kern/sys_generic.c
Right.
> If there are no equal file descriptors in different pollfd arrays,
> current maxfiles limit should not be reached.
You can set the fd member of a pollfd to a negative value,
marking the entry as unused. This allows you to easily
exceed the per-process limit which is currently in place.
Referring to IEEE 1003.1:200x:
If the value of fd is less than 0, events shall be
ignored, and revents shall be set to 0 in that entry on
return from poll( ).
> If some descriptors are equal, SGI's code is broken IMHO: when
> two different pollfd structures has identical fd, result may be
> indetermined.
Nope, poll has to check each fd. Quoting from the same
source:
The fds argument specifies the file descriptors to be
examined and the events of interest for each file
descriptor. ^^^^
FreeBSD can still claim conformance, because the
implementation can place restrictions on the maximum number
of fds. I am advocating though that this restriction can be
configured separately, because it has little relationship to
kern.maxprocfiles.
> I suppose this SGI state threads library can be simply recompiled
> to use select() instead of poll(), this can be simple workaround.
Well, historically, select(2) is the call with limitations
while poll(2) is not. I agree though that in the current
situation select is the preferred solution as I can simply
define FD_SETSIZE for my application.
> Also you can contribute code working with kevent(2), this will be
> more efficient ;)
I've actually implemented that already with no significant
speed advantage; as various papers[1] have concluded, when
select and poll are used properly they are not as inefficient
as many people seem to assume.
[1] http://www.citi.umich.edu/techreports/reports/citi-tr-00-4.pdf
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
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.LNX.4.33.0106171356230.4306-100000>