Re: [RFC] Missing sleep function for mingw hosts

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 29 Mar 2011 17:06:34 -0700
> From: Matt Rice <ratmice@gmail.com>
> Cc: pedro@codesourcery.com, gdb-patches@sourceware.org, 
> 	pierre.muller@ics-cnrs.unistra.fr
> 
> On Tue, Mar 29, 2011 at 3:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >
> > Aha, and all that for a function whose definition, including empty
> > lines and comments, is 14 lines (10 lines without that slack).
> > Typical.
> >
> 
> except it allows one to remove those 14 lines from gdb proper,
> and call the sleep with impunity.

I don't see why removing a few lines from GDB is a virtue in itself
that justifies such a sledgehammer.

> we & others benefit from the portability problems which we & they encounter.
> like if it works with values of 49 or 29 days on various platforms.

What, you mean we need in GDB to have features that sleep for 29 days?

> you forgot that gdb_usleep depends on gdb_select which has 2 implementations
> of either 134 or 3 lines which gnulib also has a module for.
> 
> so thats 147 lines of c code that could potentially be removed,
> allowing gdb to focus on being a debugger
> rather than a debugger with an ad-hoc portability layer.

I wasn't comparing gdb_usleep with gnulib's sleep.  I was comparing
gnulib's sleep with what the solution of the problem at hand should
be.  The problem is the lack of a `sleep' function in the MinGW
runtime.  The solution to this problem is a trivial 5-liner.  The
gnulib ``solution'' to the same problem is a much larger module.  (You
conveniently dismissed some of what that would bring into a package
that wants to use `sleep' on the ground that GDB already has that for
other needs.  But in judging the elegance of a solution, those other
dependencies should not be forgotten.)

Frankly, I'm amazed how people don't see the inelegance of these
massive ``solutions''.  Is that just because they conveniently allow
us to forget about the problem we needed solve?  Me, I like the
libiberty style: get a problem solved in the most direct and efficient
way that can exist.  This is what engineering is all about, IMO.

Anyway, this will be my last post on this issue, since (a) we
obviously disagree, and (b) it is pointless to argue, as a solution is
already available.