Problem with signals & exceptions...

[Tres Seaver]

In article <DA4B3986E94F79C9.E3C10FB44F334D06.D3443001EBA1A2FA at lp.airnews.net>,
Eric Lee Green  <eric at estinc.com> wrote:
>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 ???. 

About the _only_ thing one can both portably and safely do in a signal handler
(in C) is to set a global of type sig_atomic_t.  Anything else leaves one open
to the vagaries of the libc / compiler implementor's tortured imagination.

>
>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!). 

If you think about it, signals are not even guaranteed to share the stack with
the code they interrupt, so how can poor python unwind said beast if you try
to throw an exception from one?  Oh, well, at least you ended up in the right
place :).
-- 
---------------------------------------------------------------
Tres Seaver           tseaver at palladion.com       713-523-6582
Palladion Software    http://www.palladion.com