On Thu, May 27, 2010 at 1:39 PM, Marko Kreen <markokr@xxxxxxxxx> wrote: > On 5/27/10, 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. >> >> If we decide to go this route, perhaps it'd make sense to change to >> this code for Windows also? Our Windows-implementation of poll() has >> some annoying limitations... > > Example of poll() compat without FD_SETSIZE limit: > > http://github.com/markokr/plproxy-dev/blob/master/src/poll_compat.c > How does this code convince FD_SET() that the buffer has increased? It looks to me like it depends on a specific FD_SET() implementation... For instance, Windows' FD_SET() implementation is like this: #define FD_SET(fd, set) do { \ if (((fd_set FAR *)(set))->fd_count < FD_SETSIZE) \ ((fd_set FAR *)(set))->fd_array[((fd_set FAR *)(set))->fd_count++]=(fd);\ } while(0) ...so unless another set is passed in, it won't add any more fds once fd_count reaches FD_SETSIZE. Also, FD_SETSIZE is 64 on Windows. IIRC it's 1024 on Linux, so it is much more likely that we encounter this issue on Windows than on Linux, at least ;) -- 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