select() interruption by signal

[Jeremy Hylton]

>>>>> "FL" == Fredrik Lundh <fredrik at pythonware.com> writes:

  FL> Robert Longstaff <spooky at dreamfish.freeserve.co.uk> wrote:
  >> However I've found that this alarm signal, although being caught
  >> successfully by the handler, also interrupts the select() causing
  >> the app to bomb out:
  [traceback omitted]
  >> 
  >> Is this just a timing thing? Is the select() 'catching' the
  >> signal at the same time as the handler or is the signal 'hanging
  >> around' longer than it should?

When a user program is blocked on a system call* and catches a signal,
the system call is interrupted and, in Python, raises the exception
you saw.  So it's just a timing thing.  If the select had returned
sooner, it wouldn't have been interrupted.

(*) Actually, not every system call will be interrupted.  Some calls,
    like disk IO, are interrupted.

  >> Is there an option to get the select() to ignore signals or
  >> should I trap the exception (and throw it away)? I can't find any
  >> more information in the Python manual or man select. I'm using
  >> v1.5.1 on Linux.

I believe there are some nasty ways to do this for specific platforms,
but I'm not familiar with any of them.  Check out Stevens' Advanced
Programming in the Unix Environment (or hope that Donn Cave responds
:-) for some more detail.

I suppose its worth mentioning that the issue of interrupted system
calls comes up in some interesting places.  Although neither of these
papers are directly relevant to your particular problem, they do touch
on the issue:
    http://www.jwz.org/worse-is-better.html
    http://www.cs.brandeis.edu/~bawden/ftp/pclsr.memo.gz

Jeremy