On Thu, May 27, 2010 at 4:32 PM, Marko Kreen <markokr@xxxxxxxxx> wrote:
> On 5/27/10, Erik Faye-Lund <kusmabite@xxxxxxxxxxxxxx> wrote:
>> On Thu, May 27, 2010 at 4:11 PM, Marko Kreen <markokr@xxxxxxxxx> wrote:
>> > On 5/27/10, Erik Faye-Lund <kusmabite@xxxxxxxxxxxxxx> wrote:
>> >> On Thu, May 27, 2010 at 3:58 PM, Marko Kreen <markokr@xxxxxxxxx> wrote:
>> >> > On 5/27/10, Erik Faye-Lund <kusmabite@xxxxxxxxxxxxxx> wrote:
>> >> >> On Thu, May 27, 2010 at 3:29 PM, Marko Kreen <markokr@xxxxxxxxx> wrote:
>> >> >> > On 5/27/10, Erik Faye-Lund <kusmabite@xxxxxxxxxxxxxx> wrote:
>> >> >> >> On Thu, May 27, 2010 at 1:00 PM, Erik Faye-Lund
>> >> >> >> <kusmabite@xxxxxxxxxxxxxx> wrote:
>> >> >> >> > On Thu, May 27, 2010 at 12:10 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> 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 ;)
>> >
>> > Pass one fd with value 70 it. Check returns error, although
>> > everything would work.
>> >
>>
>>
>> No, not with the check I posted. I checked nfds, not the value of the
>> fds themselves. nfds is clearly the size of the fds array -- if it
>> wasn't, it'd be impossible for the poll-implementation to know how big
>> the array is!
>
> Ah, ok. I though this is the nfds for select(). In this case it can
> still fail, as nfds=1 for poll() can still go over FD_SETSIZE for
> select() if the fd value is big enough. On non-windows, that is.
>
I don't quite get where one would get a fd that's value is FD_SETSIZE
or above from. I mean, FD_SETSIZE would have to be the maximum value
of a file descriptor, or else you risk open() or socket() returning
file descriptors that cannot be select()'ed. Which would just be
insane, no?
--
Erik "kusma" Faye-Lund
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html