Re: Code for testing hurdselect.c

[Samuel Thibault]

Svante Signell, le Thu 18 Oct 2012 14:55:33 +0200, a écrit :
> > > POLLNVAL
> > >         The specified fd value is invalid. This flag is only valid in
> > >         the revents member; it shall ignored in the events member.
> > > 
> > > Specifically, my interpretation of POLLNVAL is that it should be
> > > reported for each invalid fd given as input.
> > 
> > Ah.  You should have pointed to that from the start :)
> 
> The changes I made was 15 months ago, and I did not remember by heart
> when sending my code, sorry.

That's why taking notes is always a good thing to do.

> > > And my interpretation of POLLERR is that it should be reported to
> > > _every_ fd (device or stream) given as input. 
> > > 
> > > And for these cases the return code should be the number of good fds as
> > > well as bad fds, since the revents member is nonzero. (I did not come
> > > that far in my changes by then, but it could easily be done with today's
> > > knowledge! There are also other case to take care of like: POLLWRBAND
> > > etc)
> > 
> > Indeed. That's also what was completely missing in your previous
> > description. It's indeed a bug. And it has to be fixed in poll only, not
> > in select.
> 
> I can try to make an update to that code if you are interested ;)

That can be useful, yes. To have any chance of seeing it applied, you'll
however have to take care of (like any kind of patch, actually):

- avoid code refactoring which does not actually change the behavior, or
submit it separately
- avoid affecting the select() behavior: unlike poll, that one *has*
to return EBADF as soon as a descriptor is seen as bogus. So that'll
probably mean adding a parameter to _hurd_select which selects between
both behaviors.  Since that function is actually public, that actually
means introducing another function with the parameter, and making
_hurd_select just call it with choosing the "select" behavior, while
poll() will choose the "poll" behavior.

Samuel