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

[Svante Signell]

On Thu, 2013-02-14 at 23:49 +0100, Samuel Thibault wrote:
> 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.

Well, I might say I have some C programming experience (and a number of
other languages too, starting with basic and algol) but kernel
programming is new, admitted.

> > 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.

Ok, I wanted it to be written differently, from my perspective, but I've
only written application code before (and a lot of it). So for me
embedding details in a function is preferred, to keep the level of
details down (you don't see the woods because of all the trees)

> 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,

> > - 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.

Well, with my code I need a timeout of 1ms for poll, with the old code I
don't.

> > 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.

Yes, I've seen that with different versions of my patched
hurdselect.c... in the past.

> > - 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.

This argument I cannot buy: Please explain factorized code.
Hierarchical versus flat (yes this applies to SW too).

And as a final note: My latest version of hurdselect.c works,
irrespective of what gets implemented for Hurd ;.)
(no big deal really, as long as functionality is according to POSIX)