Re: Questions about patches for hurdselect.c

[Svante Signell]

On Sun, 2013-01-13 at 21:31 +0100, Samuel Thibault wrote:
> Svante Signell, le Sun 13 Jan 2013 21:18:07 +0100, a écrit :
> > > - In the poll case, on error on one descriptor, the loop shall mark
> > > POLLERR and continue, not fail altogether.
> > > 
> > > Is that right?
> > 
> > The current code errors out if it finds one FD not OK, which is a bug.
> > Irrespective of how many FDs there are, no checks are made of the input
> > data given.
> 
> Sure, but what you refer to is only one part of the story. EBADF is one
> of the "error"s I mention above.  Errors returned by translators also
> need the same fix.

One problem is already fixed by me and you for pflocal. Remains to fix
the corresponding issues for pfinet. (and maybe other ones too).

> > > > - Hopefully the code is more readable now, without causing regressions.
> > > 
> > > But it duplicates things. As I told you, we might still keep the code
> > > as-is, and just apply your poll fixes over it. The 3-split still being
> > > useful for reviewing.
> > 
> > Well, slitting into three parts made the poll case faster
> 
> Uh? Why?

I don't know, I haven't analyzed the differences, just observed them.

> > the poll case _is_ different from select, see the POSIX specs.
> 
> In a very limited way only.

I would say that even splitting more could be usable, e.g. creating a
hurdpoll.c in addition to hurdselect.c (as well as adding io_poll server
code of course)

A comment: You removed my comments about readability  and
maintainability of if-then-else constructs vs case oriented code. We
seem to have different views on code constructs.