On Fri, Aug 22, 2008 at 10:51:54AM +0200, Jim Meyering wrote: > "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > > On Fri, Aug 22, 2008 at 09:22:06AM +0100, Richard W.M. Jones wrote: > >> On Thu, Aug 21, 2008 at 02:58:30PM +0100, Daniel P. Berrange wrote: > >> > +#define VIR_EXEC_FDSET_SIZE() (sysconf(_SC_OPEN_MAX)/8) > >> > +#define VIR_EXEC_FDSET_CLEAR(set) memset((set), 0, VIR_EXEC_FDSET_SIZE()) > >> > +#define VIR_EXEC_FDSET_ON(set, fd) (set[(fd)/8] |= (1 << ((fd)%8))) > >> > +#define VIR_EXEC_FDSET_OFF(set, fd) (set[(fd)/8] &= ~(1 << ((fd)%8))) > >> > +#define VIR_EXEC_FDSET_ISON(set, fd) (set[(fd)/8] & (1 << ((fd)%8))) > >> > >> +1 although I'm interested to know why you didn't just use ordinary > >> FD_SETs for this. > > > > For some reason I have it in my head that fd_set was limited to 32 > > but looking at the Linux source its clearly 1024, which is the sme > > as my _SC_OPEN_MAX. The manpage says its FD_SETSIZE, but doesn't > > clarify whether FD_SETSIZE is guarenteed to be large enough to store > > any FD upto _SC_OPEN_MAX. > > > > Jim, any thoughts on this ? I'll happily switch to fd_set if we expect > > it'll be suitable > > AFAIK, FD_SET must work for any valid file descriptor. > > The fd_set bit-manipulation function/macros like FD_SET, FD_CLR > are specified in http://www.opengroup.org/susv3xsh/select.html Ok, I'll redo this patch Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list