From: Erik Faye-Lund Date: Thu, 27 May 2010 14:44:03 GMT Subject: Re: [PATCH] compat: Add another rudimentary poll() emulation Message-ID: In-Reply-To: On Thu, May 27, 2010 at 4:32 PM, Marko Kreen wrote: > On 5/27/10, Erik Faye-Lund wrote: >> On Thu, May 27, 2010 at 4:11 PM, Marko Kreen wrote: >>  > On 5/27/10, Erik Faye-Lund wrote: >>  >> On Thu, May 27, 2010 at 3:58 PM, Marko Kreen wrote: >>  >>  > On 5/27/10, Erik Faye-Lund wrote: >>  >>  >> On Thu, May 27, 2010 at 3:29 PM, Marko Kreen wrote: >>  >>  >>  > On 5/27/10, Erik Faye-Lund wrote: >>  >>  >>  >> On Thu, May 27, 2010 at 1:00 PM, Erik Faye-Lund >>  >>  >>  >>   wrote: >>  >>  >>  >>  > On Thu, May 27, 2010 at 12:10 PM, Jonathan Nieder 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