Re: [PATCH] compat: Add another rudimentary poll() emulation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!

-- 
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]