Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished

[Samuel Thibault]

Svante Signell, le Wed 13 Feb 2013 07:24:46 +0100, a écrit :
> Problem is that he did not give any hints on _how_ to make the
> rewrite. If introducing the SELECT_ERROR had been discussed (or
> allowed to introduce) my solution would have been different too.

As I mentioned yesterday, I couldn't have thought about it before seeing
your change. That's one of the places where "release often, release
early" applies.

> > If it's easier for
> > us, it's also faster, and we can more effectively concentrate on
> > thinking about the big picture and the details. The second is to reduce
> > the likeliness of regressions. Please keep that in mind.
> 
> Yes, the risk of regressions increase proportionally to the number of
> changes. But sometimes, introducing fixes for every corner case in an
> old design can create other bugs and/or side effects.

Yes, but revamping everything is a much more risky approach, especially
when dealing with the most complex Unix call, select/poll, and without
so much C programming experience.

> It's all a matter of hierarchical versus flat design methodology.

The current code already has some hierarchy: some common select/poll
code, then a divergence, then common code, then divergence again, and
return.  I find this easier to understand than moving code into a
function whose behavior has to be defined properly.

Svante Signell, le Wed 13 Feb 2013 06:51:29 +0100, a écrit :
> On Wed, 2013-02-13 at 01:53 +0100, Samuel Thibault wrote:
> > Samuel Thibault, le Wed 13 Feb 2013 01:42:53 +0100, a écrit :
> > > I have rewritten your changes as seen below,
> > 
> > and pushed to our glibc repository. This is all above Richard's
> > io_select_timeout changes.
> 
> Where? I cannot find it. Its not at
> http://git.savannah.gnu.org/cgit/hurd/glibc.git/ or

It *is* there.

$ git clone git://git.sv.gnu.org/hurd/glibc.git
$ cd glibc
$ git checkout youpi/poll_errors_fixes

> - the rewritten code is faster than the old one. In the old code no
> delay is needed for the POLL case but is for the rewritten code. i.e.
> it's faster. (irrespective of moving timeouts to the server side or not)

I don't understand what you mean.  What delay are you talking about?
The only delay in by branch is the delay requested by the user.

> - in a better world the hurdselect.c code should be split into two
> routines: hurdselect.c and hurdpoll.c with corresponding changes on the
> server side.

No.  Duplicating code is asking for later seeing fixes go one side, but
not the other, etc.

> The code paths are too different to squeeze into one
> function.

It's still quite similar

> But nobody dares (or is allowed to) to make major changes
> nowadays. Incremental development is not always the best way to make
> progress.

Not always, yes.  But with select/poll(), I can tell you it is: it's way
to easy to break it.

> - regarding programming style: Let's assume you develop a microprocessor
> containing several millions of gates. Which solution is most easily
> developed, maintained, reviewed and bug fixed: A flat netlist design or
> a hierarchical design? Just ask the chip developers, like Intel and AMD.

That's why keeping code factorized is important.

Samuel