From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 16:34:39 +0200

>...
>Concluding, I think Vladimir is better off not to use signal handlers
>in the way he is using them now.  Python's emulation of signal
>semantics is sufficiently different from C that you can't rely on the
>same behavior.  (And note that in C, signal handlers are usually
>broken anyway; e.g. the code you write, which prints something inside
>the signal handler, is broken on C too because you don't know the
>state of stdout when the handler is invoked.)


    Well, meantioned programs were only very simple demos for demonstrate
incorrect signal processing. But exists a large range of meaningful programs
where is necessary both synchronous and asynchronous signal processing - and
signal can be triggered whenever.

    Example of C symbolic structure this programs:

....
int event_flag;
void trigger_signal(int signum) {
  // asynchonous signal processing
  event_flag = MY_EVENT; // only flag set
}
void initialize_signal(int sig) {
  event_flag = NO_EVENT; // initialize
  signal(sig, trigger_signal);
}
int main() {
  initialize_signal(SIGTERM);
  while (1) {
    my_func();
    // synchronous signal processing:
    if (event_flag==MY_EVENT) my_sync_trigger();
  }
}

    Signal can be raised whenever when function my_func runs => flag
event_flag is then set but my_func "does't know" his and continues at own
processing. Signal should not influence my_func becouse my_func "doesn't
know" both this signal and flag event_flag. Function event_flag can wait for
system call (read, write, connect, etc). Incoming signal should not finish
this waiting after trigger_signal function processing. So my_func is
independed on signal processing and "does'nt know" signals.

    Program tests the flag at any "safe" location(s). If this flag is set,
program run specific synchronous signal processing. It can be for example
safe program end or synchronous SIGALRM processing.

    Python programs can by compose similar this example.

>I looked at what could be different between 1.5.1 and 1.5.2, and found
>that the call to siginterrupt() to disable restarting system calls was
>added after 1.5.1.  Given the alternatives, I think I like the 1.5.2
>behavior better than the 1.5.1 behavior.


    But then old Python programs writen for Python 1.5.1 are not compatible
with Python 1.5.2. in this feature. I thing that better way is to let this
behavior equal as in Python 1.5.1. but allow programs to call either new
function "siginterrupt" at signal module (more flexible solution) or any
else new function at signal module to set behavior signal processing by Your
idea.

        Good bye, V. Benes