Python signal delivery under BSD 4.4
andymac at bullseye.apana.org.au
Thu Aug 14 15:04:16 CEST 2003
On Wed, 13 Aug 2003, Donn Cave wrote:
> In article <m3n0eds0bd.fsf at drizzle.com>,
> "Elf M. Sternberg" <elf at drizzle.com> wrote:
> > However, this variant worked as I've reported:
> [... forks from thread ]
> I tried it from FreeBSD 5.1, using 2.2.2 built from ports,
> and didn't see this problem. I believe 5.1 has a significantly
> different thread implementation from 4.x, though.
And later releases of FreeBSD 4.x have a number of bugfixes to the pthread
support, including some signal related changes. The 4.x pthread support
still has some issues though.
Elf refers to this working with Python 2.1 - I vaguely recall some changes
to Python's pthreads support to try and "harmonise" the behaviour across a
number of platforms, and signal delivery may have been affected such that
signals are only delivered to the primary thread. As this is only a vague
recollection, treat with caution...
Does building Python with the linuxthreads port, instead of FreeBSD's
native pthreads, behave as expected?
> Note that there is pthread_sigmask(3) with the same arguments as
> sigprocmask(2), and Python's thread_pthread.h does appear to block
> all signals that way when starting a new thread. That's a clue,
> perhaps. If sigprocmask() didn't show any signals blocked, maybe
> pthread_sigmask() would, or maybe at any rate you can set the
> mask to 0 using one or the other of those functions.
I also recall Michael Hudson trying to get signal mask support working in
the presence of threads, but he could only get it to work on Linux. We
did eventually get a required fix to FreeBSD's libc_r committed (in the
4.7 timeframe I think), but Michael had given up by then and canned his
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370
andymac at pcug.org.au (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
More information about the Python-list