This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nobody
Date 2000-07-31.21:05:11
SpamBayes Score
Marked as misclassified
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 09:19:44 +0200

From: Jeremy Hylton <>
To: <>
Cc: <>; <>
Date: 12. 10. 1999 18:04
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python
1.5.2 (PR#102)

JH>I see the behavior you report for 1.5.2 on Solaris 2.6.

    You don't write whether this bug appeared there.

 JH> ......  I'm not sure that the
 JH> behavior you're seeing is a bug; it is the behavior I would expect.
 JH> Slow system calls are interrupted, returning EINTR, when a signal
 JH> occurs.

    I'am sure that this behavior is bug becouse:

1. I wrote the same program in C language (see below).
2. I ran this program at the same machine where the Python *)
    program works incorrectly.
3. Behavior of C program is correct (line scan is ended only when
    user press ENTER and this end is independed on signal).

=> The C program works correct and the same Python *) program fails at the
same platform. Base run of program should by independed on signal processing
except program terminating signals. It's independed at C program but
incorrect processed by Python *) programs.

*) only Python 1.5.2; Python 1.5.1 here works correctly

    Here is the mentioned program:

#include <unistd.h>
#include <signal.h>

void signal_handle(int signum) {
  signal(SIGALRM, signal_handle);

void main(void) {
  char a[100], b[100];

  printf("Line examined...\n\r");
  printf("Line examined...\n\r");
  printf("%s\t%s\tend\n\r", a, b);

 VB>     Bug is perhaps caused by wrong seting "siginterrupt" on
 VB> module signal. I haven't found any way how call in Python
 VB> program "siginterrupt" for correct behavior of signal
 VB> processing.

 JH> Perhaps the signal module for Python should be extended to support
 JH> siginterrupt, but it sounds like it will only reduce the number of
 JH> system calls that can be interrupted.  .......

    Sorry, I wrong formulated possible couse of bug. I will try to specify
my idea:
    It looks that there is any wrong calling "siginterupt" on signal module.
Python libraries doesn't allow me to try correct this bug by calling
"siginiterrupt" in my program before signal setting. But the best way is to
reapir bug on signal module.

    Good bye, V. Benes

Date User Action Args
2007-08-23 13:49:03adminlinkissue210599 messages
2007-08-23 13:49:03admincreate