Signal-handling question

[Gary Robinson]

In some code we're writing we're making an assumption, and I'd like to
confirm that the assumption is valid.

Suppose a signal arrives while a file is being written, and the signal
handler explicitly raises a SystemExit exception.

My understanding is that the C-level I/O code will continue and the signal
won't be processed until the end of the atomic python interpreter
instruction that invoked that C code.

Then, the signal handler is executed, including the SystemExit.

Are we guaranteed that there are no circumstances under which any more file
I/O will be carried out by the interrupted code after the signal handler is
invoked? That is, are we guaranteed that the SystemExit raised by the signal
handler will immediately terminate the interrupted call to write()?

The answer seems to be "obviously YES" but I need to be sure so I thought it
was worth asking.

Thanks--

--Gary

--
Putting http://wecanstopspam.org in your email helps it pass through
overzealous spam filters.

Gary Robinson
CEO
Transpose, LLC
(e-mail address removed)
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

 

[Donn Cave]

Quoth Gary Robinson <[email protected]>:
| In some code we're writing we're making an assumption, and I'd like to
| confirm that the assumption is valid.
|
| Suppose a signal arrives while a file is being written, and the signal
| handler explicitly raises a SystemExit exception.
|
| My understanding is that the C-level I/O code will continue and the signal
| won't be processed until the end of the atomic python interpreter
| instruction that invoked that C code.
|
| Then, the signal handler is executed, including the SystemExit.
|
| Are we guaranteed that there are no circumstances under which any more file
| I/O will be carried out by the interrupted code after the signal handler is
| invoked? That is, are we guaranteed that the SystemExit raised by the signal
| handler will immediately terminate the interrupted call to write()?

I can't say I really know the details for sure, but here are a couple
of questions and observations.

- What interrupted call to write()? I thought your C I/O call was
going to complete. I believe that's correct, it will complete,
if it's really to disk, or if you get BSD-style restartable I/O
on your platform. If so, the output goes out, even if after the
delivery of the signal and the execution of the Python-internal
C signal handler. At the system call level, at any rate, there
isn't anything to terminate by the time the Python code runs.

- If writing to a pipe or something and I/O isn't restartable, write
will raise an exception; don't know for sure when the signal handler's
Python code will run in this case, presumably before the exception
handlers but I'm just guessing.

- But you're probably not really calling posix.write, are you? The
Python file object uses C stdio functions like fwrite(3). In this
case, the effect should be similar, but different in a way that you
may care about, I can't tell. The thing is, C stdio output doesn't
actually write all the data to disk. The rest typically is written
on fclose(3), which is automatically done at process exit, whether
Python closes the file objects or not. In this case, the data is
still all from writes issued prior to the Python code signal handler,
but some of it is written to disk afterwards.

Donn Cave, (e-mail address removed)