Re: select/poll bug?

[David Young <dyoung%pobox.com@localhost>]

On Sat, Aug 02, 2008 at 08:18:37PM +0100, Roy Marples wrote:
> On Saturday 02 August 2008 17:11:17 David Brownlee wrote:
> > On Sat, 2 Aug 2008, Roy Marples wrote:
> > > On Sat, 2008-08-02 at 11:25 -0400, Christos Zoulas wrote:
> > >> On Aug 2,  4:12pm, roy%marples.name@localhost (Roy Marples) wrote:
> > >> -- Subject: Re: select/poll bug?
> > >>
> > >> | On Sat, 2008-08-02 at 14:26 +0000, Christos Zoulas wrote:
> > >> | > On NetBSD you should use pollts(2) I think.
> > >> |
> > >> | pselect is more portable I would guess, but platforms like OpenBSD
> > >> | lack either. I could trivially add a pselect wrapper for systems that
> > >> | lack it. But would pselect avoid the need to artifically reduce my
> > >> | timers on ALL platforms?
> > >> |
> > >> | I'll test it :)
> > >>
> > >> The select family of system calls is generally inferior to poll because:
> > >>
> > >> 1. Expensive because you need do operations on bitmasks [ffs/shifts].
> > >> 2. Expensive because you need to reset the masks before each call.
> > >> 3. Non portable behavior for >= 256 fd's. All systems need source
> > >>    recompilation; some older systems need kernel recompilation.
> > >> 4. Non-portable behavior with respect to ERESTART.
> > >> 5. Non-portable behavior when running out of resources. The only
> > >>    way to fix this is using non-blocking-io which is a bit of a pain.
> > >> 6. Non-portable behavior with respect to "struct timeval *timeout".
> > >>    This is non-const, and it was originally intended to return
> > >>    the time left. Most implementations did not change "timeout", but
> > >>    one or two did, so it is always good to re-initialize "timeout".
> > >> 7. Can only report 3 types of events, read/write/except.
> > >
> > > Only 1 & 2 would apply here I think. We only monitor 4 fd's which are
> > > all non blocking, we don't care about modified timeval and I only care
> > > if something is to be read from the fd.
> > >
> > > Linux has ppoll, NetBSD has pollts - no other platform has any
> > > equivalents I can find.
> >
> >     At least ppoll() and pollts() appear to take the same
> >     arguments, so handling both of them is not too much of
> >     a PITA... plus maybe a compat shim down to poll() for
> >     everything else?
> 
> OK, testing shows at select, pselect and pollts all suffer the same flaw, so 
> it now boils down to which one is best for dhcpcd.
> 
> select is 100% portable in terms of how it is used by dhcpcd.
> pselect should be as it's mandated by POSIX, but OpenBSD lacks it. However a 
> simple wrapper is trivial.
> ppoll/pollts are platform specific functions.
> poll itself is NOT suitable as the timeout cannot handle a DHCP lease of 
> uint32_t seconds on 32-bit platforms.

Roy,

Perhaps Niels Provos' libevent---see event(3)---is suitable for dhcpcd?
I believe that it is highly portable, and it will correctly use the best
available mechanism (select/poll/kqueue) to schedule events.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24