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
Recipients
Date 2000-07-31.21:05:10
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
From: Jeremy Hylton <jeremy@cnri.reston.va.us>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Tue, 12 Oct 1999 12:04:42 -0400 (EDT)

>>>>> "VB" == Vladimir Benes <Vladimir.Benes@pvt.cz> writes:

  VB> Bug: Incorrect signal processing (Python 1.5.2).  Process can
  VB> assign procedure for signal processing. When process is waiting
  VB> at system call and this signal occur, then the signal assigned
  VB> procedure is otherwise correctly completed but then waiting at
  VB> system call is broken and process continues.

[example program]

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

  VB>     This bug appears at any signal occur and whatever process
  VB> waiting at system call. Some system call even produces exception
  VB> (e.g. waiting for data or connection on socket).

These issues always occur in twos don't they.  There was a similar
question posted on comp.lang.python yesterday.  I'm not sure that the
behavior you're seeing is a bug; it is the behavior I would expect.
Slow system calls are interrupted, returning EINTR, when a signal
occurs. 

  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.

Perhaps the signal module for Python should be extended to support
siginterrupt, but it sounds like it will only reduce the number of
system calls that can be interrupted.  The Solaris man page says:

    NOTES
         Use of these interfaces should be restricted to only  appli-
         cations  written  on BSD platforms.  Use of these interfaces
         with any of the system libraries or in multi-threaded appli-
         cations is unsupported.

It doesn't sound particularly safe.

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