Re: signal-handling problems for "dd": some thoughts

[Paul Eggert]

(Note to Miika Pekkarinen: this email replies to this thread
http://mail.gnu.org/archive/html/bug-coreutils/2004-04/msg00128.html
on problems with the SIGUSR1 signal in "dd".)

Jim Meyering <address@hidden> writes:

> Lots of people have been asking for progress-bar support
> in the coreutils over the years.  Here's a related idea and
> some code to provide progress-bar support for several of the
> coreutils programs:
>
>   http://mail.gnu.org/archive/html/bug-coreutils/2004-02/msg00071.html

I looked at this and I think it suffers from the same problems with
SIGUSR1: the code has several race conditions and can screw up its own
output buffers.

I'd like to implement this sort of thing in a slightly different way,
by having the utilities output status lines regularly when given an
option to do so.  For example, we might have "dd stats=1" generate
output lines like this, (say) once per second:

dd[2341]: 341324/91231329 23s outputfilename

That is, it prints dd's name, process ID, bytes copied, total bytes,
seconds so far, and the output file name.

Simplest would be to just send this to stderr.  We could get fancier,
let the user specify where to send it to, what format, how often to
generate it, etc.  Not sure how useful this all would be if users
prefer to run a status-bar program anyway.

The advantage of this approach is that you don't need to use any
signals and this greatly simplifies "dd" and will make it more
reliable.


>> However, I don't see any way of implementing it reliably for slow
>> devices....
>
> Why not?
> Because we can't rely on signal semantics to defer signals
> while in the critical read or write sections?

Yes, that's right.  We can't block signals while reading (because
then, the read might hang and we might ignore signals indefinitely),
and we can't not block them either (because they might interrupt the
read, and this messes up dd's block boundaries).

"dd" is perhaps a special case because it really cares about short
reads.

It might be possible to work around this by using "select" before each
read and/or write; also by having multithreaded apps.  Both of these
are kind of heavyweight options, though, and I suspect they'll suffer
from their fair share of porting bugs.

> The ideal would be to find an approach that avoids adding a new option
> to each tool that supports a progress bar.

I suppose it could be an environment variable, listing the
progress-bar options.  But how many coreutils programs are we talking
about here?  If it's just cp and dd it might be simpler just to add
options.