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