Wandering Thoughts archives


Link: Using colour well in data visualization

Why Should Engineers and Scientists Be Worried About Color? is about how straightforward use of colour in data visualizations can mislead you and hide information (and how to do better). Some of their examples are eye-opening and alarming.

(Via Hacker News.)

(Since I took up photography I've had a much increased interest in how we perceive things, including colour.)

links/ColourVisualizations written at 15:01:18; Add Comment

Python, signal handlers, and EINTR

One of the interesting effects of setting a signal handler in your Python program is, well, let me quote the signal module:

  • When a signal arrives during an I/O operation, it is possible that the I/O operation raises an exception after the signal handler returns. This is dependent on the underlying Unix system's semantics regarding interrupted system calls.

By 'an I/O operation' the manual means more than you might think; for example, select.select() is affected by this. (This is where the whole socket error boondoggle becomes very irritating.)

In general, on Unixes that behave this way, signals that are handled during 'slow' operations (especially IO-related ones) normally cause the system call to fail with an EINTR error. Which system calls this affects and under what circumstances is system dependent, but you generally can count on it affecting at least socket operations, talking to the user's terminal, and things like wait().

(And some system calls don't fail with EINTR but instead return partial results if, for example, they have already transmitted part of your write() on a socket.)

When CPython sees that a system call failed, it raises an exception. It pretty much doesn't do anything special when EINTR is the 'failure' reason; you still get a Python level exception, and it is up to you to notice that this failure is not really a failure and you should retry the operation, assuming that you can and want to.

(There are cases where you cannot; for example, I believe that socket.sendall() can be hit with an EINTR despite having sent some of the buffer, at which point you get an exception instead of a partial result.)

It is my personal feeling that given Python's rich exception handling, your low-level Python code should always retry operations when you get an EINTR-based exception. If a signal handler actually wants to abort or redirect the program, it can easily do this by raising an appropriate exception; in the mean time, your low-level code is in the best position to retry the aborted system call.


On Unixes that have EINTR, you can usually tell the kernel that you actually don't want your system calls interrupted just because a particular signal handler got called by setting the SA_RESTART flag on the signal handler. Unfortunately, Python does not expose this, even on systems that support it.

Somewhat to my surprise, the GNU libc texinfo documentation has a decent discussion of signals, EINTR, and SA_RESTART.

python/PythonEINTR written at 00:47:28; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.