Re: select/poll bug?

[Roy Marples <roy%marples.name@localhost>]

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.

Thanks

Roy