[PATCH] Properly handle short writes in sigint handlers

Tomi Ollila tomi.ollila at iki.fi
Fri Dec 23 04:30:50 PST 2011


On Fri, 23 Dec 2011 08:10:33 +0000, David Edmondson <dme at dme.org> wrote:
> Sorry for being slow.
> 
> Can you describe the situation in which you expect a write to stderr to
> be a short write? (Without error.)

In the following hypothetical case (correct me if I'm wrong :):

* There is 4096 byte buffer in tty driver.
* Stderr is in blocking-mode (the usual case).
* There is already 4090 bytes in that buffer that has not been read.
* One attemtps to write "Stopping...         \n" there (blocks).
* Somehow the system call is interrupted (and SA_RESTART not set)
  -- write() should return 6 bytes written.

But, if the buffer is full already, does the write() system call return
with -1 and EINTR set ?

If there is enough space for all data in that buffer to begin with, 
write() should be atomic.

> In that situation, what guarantee is there that the loop you've written
> will terminate?

If write() keeps returning 0 then it will not terminate (I guess this never
happens). Also, it never terminates if write blocks indefinitely 
(with or without that loop).

> We're not talking about safeguarding a users' data here - this is a
> short message to indicate that a tool is terminating due to a signal.
> I'm concerned that the solution is worse than the problem.

I'm also in favor of "opportunistic" write *in this particular case*

In case that write fails there is most probably more serious things going
on (all resources eaten, hardware problem, etc) and trying to push these
writes forward doesn't help.

Tomi


More information about the notmuch mailing list