Problem with signals & exceptions...

[Eric Lee Green]

Donn Cave wrote:
> 
> Eric Lee Green <e_l_green at hotmail.com> writes:
> | I'm having trouble catching my thrown exceptions under FreeBSD 3.2. I am
> | using the Python 1.5.2 that came with FreeBSD 3.2 (well, on disk 1 of
> | the <n>-disk set). The following program works properly under Red Hat
> | Linux version 6.0 running a self-compiled Python 1.5.2 (in place of the
> | 1.5.1 which comes with Red Hat 6.0, which does not properly handle
> | signals during socket i/o calls). How it works: it listens to port 6664.
> | When it gets a connection, it then sets an alarm handler and alarm and
> | then tries to read from the socket. If it does not get data within 10
> | seconds, it then times out, at which point the alarm handler throws an
> | exception and aborts the socket read.
> 
> I tried this exception-from-handler notion on Digital UNIX and BeOS,
> and it does seem to work the way I guess you expect, but I do find it
> weird. A signal handler executes outside the normal flow of control,
> so it's not obvious to me where its exceptions ought to surface.
> Probably it should be expected to work the same way on various platforms
> for any given version of Python, but would future versions of Python be
> guaranteed to work this way also?

That, of course, is the ten million dollar question. The operation of signals
in "C" is extremely well documented and described. Under Python, it's ???. 

I changed my code to set a global variable rather than throw an exception and
that works the way you'd expect. A socket.error exception is thrown, and I
catch it, check the global variable, if the global variable is set I print "got
a timeout!" else re-throw the exception. 

In the actual working code I scrapped the alarm signal altogether and instead
do a select() call with a timeout, which presumably is guaranteed to work the
same on all platforms (it better, the select call is a POSIX standard!). 

-E