[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Svante Signell
Subject: Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished
Date: Wed, 13 Feb 2013 06:51:29 +0100

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
http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/ or

There are still a few issues to handle:

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

- you cannot commit this code unless I agree to sign the copyright
papers for libc (which I of course will when asked for). This is a
derived work of mine. Otherwise it has to stay as a Debian patch.

- 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. The code paths are too different to squeeze into one
function. But nobody dares (or is allowed to) to make major changes
nowadays. Incremental development is not always the best way to make

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]