[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file21735/signal_pthread_sigmask.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[STINNER Victor]

STINNER Victor  added the comment:

Oh, I forget to read again http://codereview.appspot.com/1132041.

Here is an updated patch reusing some tests and with a better documentation.

--
Added file: http://bugs.python.org/file21736/signal_pthread_sigmask-2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[STINNER Victor]

STINNER Victor  added the comment:

signal_pthread_sigmask.patch:
 - add signal.pthread_sigmask() function with doc and tests
 - add SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK constants
 - fix #11859: fix tests of test_io using threads and an alarm: use 
pthread_sigmask() to ensure that only the main thread receives the SIGALRM 
signal

The code is based on the last version of python-signalfd:
https://code.launchpad.net/~exarkun/python-signalfd/trunk

Changes between python-signalfd and my patch:
 - rename "sigprocmask" function to "pthread_sigmask"
 - I added an unit test and the doc
 - catch PyIter_Next() error
 - set signum variable (the result of PyLong_AsLong) type to long (instead of 
int) and check its value (0 < signum < NSIG)
 - I adapted the code to my coding style :-)

I will work on a similar patch for signalfd() after the pthread_sigmask() patch 
is accepted.

--
keywords: +patch
Added file: http://bugs.python.org/file21735/signal_pthread_sigmask.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[STINNER Victor]

STINNER Victor  added the comment:

sigprocmask or (better) pthread_sigmask is required to fix #11859 bug.

---

Python has a test for "broken pthread_sigmask". Extract of configure.in:

  AC_MSG_CHECKING(if PTHREAD_SCOPE_SYSTEM is supported)
  AC_CACHE_VAL(ac_cv_pthread_system_supported,
  [AC_RUN_IFELSE([AC_LANG_SOURCE([[#include 
  void *foo(void *parm) {
return NULL;
  }
  main() {
pthread_attr_t attr;
pthread_t id;
if (pthread_attr_init(&attr)) exit(-1);
if (pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM)) exit(-1);
if (pthread_create(&id, &attr, foo, NULL)) exit(-1);
exit(0);
  }]])],
  [ac_cv_pthread_system_supported=yes],
  [ac_cv_pthread_system_supported=no],
  [ac_cv_pthread_system_supported=no])
  ])
  AC_MSG_RESULT($ac_cv_pthread_system_supported)
  if test "$ac_cv_pthread_system_supported" = "yes"; then
AC_DEFINE(PTHREAD_SYSTEM_SCHED_SUPPORTED, 1, [Defined if 
PTHREAD_SCOPE_SYSTEM supported.])
  fi
  AC_CHECK_FUNCS(pthread_sigmask,
[case $ac_sys_system in
CYGWIN*)
  AC_DEFINE(HAVE_BROKEN_PTHREAD_SIGMASK, 1,
[Define if pthread_sigmask() does not work on your system.])
;;
esac])

Extract of Python/thread_pthread.h:

/* On platforms that don't use standard POSIX threads pthread_sigmask()
 * isn't present.  DEC threads uses sigprocmask() instead as do most
 * other UNIX International compliant systems that don't have the full
 * pthread implementation.
 */
#if defined(HAVE_PTHREAD_SIGMASK) && !defined(HAVE_BROKEN_PTHREAD_SIGMASK)
#  define SET_THREAD_SIGMASK pthread_sigmask
#else
#  define SET_THREAD_SIGMASK sigprocmask
#endif

---

Because today more and more programs rely on threads, it is maybe not a good 
idea to provide a binding of sigprocmask(). I would prefer to only add 
pthread_sigmask() which has a determistic behaviour with threads. So only 
compile signal.pthread_sigmask() if pthread API is present and pthread_sigmask 
"is not broken".

---

About the patch: the doc should explain that the signal masks are inherited for 
child processes (fork() and execve()). I don't know if this behaviour is 
specific to Linux or not.

If we only use pthread_sigmask(), the doc is wrong: "Set the signal mask for 
the process." It's not for the process but only for the current thread.

How does it work if I change the signal mask of the main thread and then I 
create a new thread: the signal mask is inherited, or a default mask is used 
instead?

---

The new faulthandler uses a thread to implement a timeout: the thread uses 
pthread_sigmask() or sigprocmask() to ignore all signals. If I don't set the 
signal mask, some tests fail: check that a system call (like reading from a 
pipe) can be interrupted by signal. The problem is that signal may be send to 
the faulthandler thread, instead of the main thread. Hum, while I'm writing 
this, I realize that I should maybe not fallback to sigprocmask() because it 
may mask signals for the whole process (all threads)!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Michael Schurter]

Michael Schurter  added the comment:

Any hopes of getting this into Python 3.3?

--
nosy: +schmichael
versions: +Python 3.3 -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Let's leave it for 3.2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> If everyone agrees this is inappropriate for 2.7

I think the decision is up to Benjamin.

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

I think this is ready for a first review.  See 
.  If everyone agrees this is 
inappropriate for 2.7, then I'll port the changes to 3.x.  I don't expect there 
to be much difference in the 3.x version.

--
keywords: +needs review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Tres Seaver]

Tres Seaver  added the comment:

Trying pthread_sigmask first, and falling back, seems like the right strategy 
to me.

--
nosy: +tseaver

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> pthread_sigmask should be used instead.  I could either expose both of > 
> these and let the caller choose, or I could make signal.sigprocmask use > 
> pthread_sigmask if it's available, and fall back to sigprocmask.

Or perhaps you could disable the feature if pthread_sigmask isn't available. 
Apparently, FreeBSD and Mac OS X have it, as well as Linux.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +gregory.p.smith -gps

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Jean-Paul Calderone]

Changes by Jean-Paul Calderone :


--
nosy: +gps

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

One open question regarding interaction with threading.  sigprocmask's behavior 
in a multithreaded program is unspecified.  pthread_sigmask should be used 
instead.  I could either expose both of these and let the caller choose, or I 
could make signal.sigprocmask use pthread_sigmask if it's available, and fall 
back to sigprocmask.  I don't see any disadvantages of doing the latter, and 
the former seems like it would create an attractive nuisance.  However, I don't 
have much experience with sigprocmask; I'm only interested in it because of its 
use in combination with signalfd.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

> The one big difference I can see is that set_wakeup_fd() doesn't transmit the 
> signal number, but this could be fixed if desired (instead of sending '\0', 
> send a byte containing the signal number).

There's a lot more information than the signal number available as well.  The 
signalfd_siginfo struct has 16 fields in it now and may have more in the future.

Another advantage is that this approach allows all asynchronous preemption to 
be disabled.  This side-steps the possibility of hitting any signal bugs in 
CPython itself.  Of course, any such bugs that are found should be fixed, but 
fixing them is often quite challenging and involves lots of complex 
domain-specific knowledge.  In comparison, the signalfd and sigprocmask 
extensions are quite straight-forward and self-contained.

It's also possible to have several signalfds, each with a different signal 
mask.  set_wakeup_fd is limited to a single fd per-process.

sigprocmask has other uses all by itself, of course, like delaying the delivery 
of signals while some sensitive code runs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm with Martin, better to target 3.2 IMO.
Does signalfd really bring something compared to set_wakeup_fd()?
The one big difference I can see is that set_wakeup_fd() doesn't transmit the 
signal number, but this could be fixed if desired (instead of sending '\0', 
send a byte containing the signal number).

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Andrew Bennetts]

Changes by Andrew Bennetts :


--
nosy: +spiv

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Marcin Bachry]

Changes by Marcin Bachry :


--
nosy: +marcin.bachry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Notice that 2.7 has seen its first beta release, so no new features are allowed 
for it. I think it's better to target this feature for 3.2.

--
nosy: +loewis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

I've started on an implementation of this in /branches/signalfd-issue8407.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

[Jean-Paul Calderone]

New submission from Jean-Paul Calderone :

Linux offers the signalfd syscall since 2.6.22 (with minor changes afterwards). 
 This call allows signals to be handled as bytes read out of a file descriptor, 
rather than as interruptions to the flow of a program.  Quite usefully, this 
file descriptor can be select()'d on (or poll()'d, epoll()'d, etc) alongside 
other "normal" file descriptors.

In order to effectively use signalfd(), the signals in question must be 
blocked, though.  So it makes sense to expose sigprocmask(2) at the same time, 
in order to allow this blocking to be set up.

--
assignee: exarkun
components: Extension Modules, Library (Lib)
messages: 103182
nosy: exarkun
priority: normal
severity: normal
status: open
title: expose signalfd(2) and sigprocmask(2) in the signal module
type: feature request
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com