Re: [PATCH] compat: Add another rudimentary poll() emulation
- From
Erik Faye-Lund <kusmabite@googlemail.com>
- Date
- May 27, 2010, 14:06 UTC
- Message-ID
- <AANLkTikDcZRHpKp9phlThK5x-8A0OfTYIlhGkqookiFj@mail.gmail.com>
- In-Reply-To
- <AANLkTiko_Azw-cXNFe11oXkijvtER2I9qiRE_gVFouht@mail.gmail.com>
On Thu, May 27, 2010 at 3:58 PM, Marko Kreen <markokr@gmail.com> wrote:
Show 46 quoted lines
> On 5/27/10, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
>> On Thu, May 27, 2010 at 3:29 PM, Marko Kreen <markokr@gmail.com> wrote:
>> > On 5/27/10, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
>> >> On Thu, May 27, 2010 at 1:00 PM, Erik Faye-Lund
>> >> <kusmabite@googlemail.com> wrote:
>> >> > On Thu, May 27, 2010 at 12:10 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> >> >> Implement the subset of poll() semantics needed by git in terms of
>> >> >> select(), for use by the Interix port. Inspired by commit 6ed807f
>> >> >> (Windows: A rudimentary poll() emulation, 2007-12-01).
>> >> >>
>> >> >
>> >> > A possible problem with this approach is that the maximum number of
>> >> > file descriptors poll can handle limited by RLIMIT_NOFILE, whereas the
>> >> > maximum number of file descriptors select can handle is limited by
>> >> > FD_SETSIZE.
>> >> >
>> >> > I don't think this is a big problem in reality, though - both values
>> >> > seem to be pretty high in most implementations. And IIRC git-daemon is
>> >> > the only one who needs more than 2, and it doesn't even check
>> >> > RLIMIT_NOFILE.
>> >> >
>> >>
>> >>
>> >> To be clear: I think this strategy is the best option (at least for
>> >> non-Windows, where select() might be our only option).
>> >>
>> >> But perhaps you should include a check along the lines of this:
>> >>
>> >> if (nfds > FD_SETSIZE)
>> >> return errno = EINVAL, error("poll: nfds must be below %d", FD_SETSIZE);
>> >>
>> >> Just so we can know when the code fails :)
>> >
>> > Well, per your own FD_SET example, the FD_SETSIZE on windows
>> > means different thing than FD_SETSIZE on old-style bitmap-based
>> > select() implementation.
>> >
>> > On Unix, it's max fd number + 1, on windows it's max count.
>> >
>>
>>
>> Are you sure this applies for all Unix, not just some given Unix-y system?
>
> Not sure. Just pointing out that the above check is not
> universal enough.
>Isn't it? How could one possibly pass more than max fd number + 1 file descriptors, since they start at 0? I guess one could specify a given fd more than once, but that'd be kind of redundant... and also very unlikely in our case ;)
-- Erik "kusma" Faye-Lund