On Sun, May 31, 2009 at 05:31:44PM +0100, Alan Cox wrote:
> O> Perhaps removing the "|| r == -EINTR" part would make both of you
> > happy?  He gets the reliability on pipes, you keep the interrupt on
> > signals.
> 
> How does that improve things.

I can very well misunderstand the code, but if you dump to a pipe,
what you can write() in one call is limited to the pipe buffer
capacity, isn't it?  Something like 16 pages iirc.  So you get a short
write and nothing there seems to call write again.

I've also had short writes on normal filesystems (nfs at least,
reiserfs and ext3 too I seem to remember, but it was a 2.6.20-era
kernel) for writes bigger than 2G.  So I'm not sure a dump of a 2G+
process would actually work.


> There is a second problem anyway. Suppose something is causing a
> continual stream of signal events - what guarantees it makes progress ?

Can a signal end up in anything else than EINTR?


> The only source of signals during a dump should be external ones. Far
> better would be to set some kind of defined signal mask during the dump
> (say SIGPIPE, SIGINT, SIGQUIT) ? I agree with Paul's patch in the sense
> we don't want spurious SIGIO events or similar spoiling a dump.

But Paul's patch is not just about signals, it's about EAGAIN and
short writes too.

  OG.