Subject: Re: default maximum number of open file descriptors too small?
To: None <tech-kern@NetBSD.ORG>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 12/01/1995 06:21:37
In article <DIu8oE.G6J@endicor.com> email@example.com (Ty Sarna) writes:
>In article <199511292207.RAA11392@glacier.MIT.EDU>,
>Greg Hudson <ghudson@MIT.EDU> wrote:
>> If we're going to abandon the current select() interface, the right
>> answer is to the use the SVR4 poll(), one of the few things System V
>> did much better than BSD. (There's the minor weakness that it uses a
>> millisecond timeout, but that's much less of a flaw than those of the
>> select() interface.)
>So, why not introduce a "upoll()", and make poll() a simple libc
>wrapper? Or even put it in the kernel, since emulations will probably
>want it anyway.
>I agree poll() is cleaner from an API standpoint. However, I fear that
>the changes to implement it in the kernel might be significant and
>If it does look doable, before tackiling the kernel you could do this as
>a proof-of-concept: start by implementing upoll() as a user-space
>wrapper on select(), and the poll() on top of it. This will be useful
>in porting NetBSD code to other OSes which have select() but not
>poll(), if NetBSD is converted. Then implement select() as a wrapper on
>upoll(), which will definately be needed if NetBSD converts. Then put
>the emulated-select()-on-emulated-upoll()-on-syscall-select() in your
>libc and run your system this way for a while. That way you can get
>all the bugs ironed out of the userspace, and even get a start on
>converting NetBSD's userspace, all before the kernel is touched.
I wrote a poll() emulation on top of select (I did not implement all
the features of poll, only the ones supported by the select interface),
which is in use by compat_sunos and compat_svr4. You can look in the
kernel sources for it. I don't think that writing select in terms of
poll or poll in terms of select is that difficult.