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 mark.dickinson
Recipients db3l, jnoller, mark.dickinson
Date 2009-11-20.14:01:57
SpamBayes Score 0.0014030007
Marked as misclassified No
Message-id <1258725719.98.0.527321479441.issue7272@psf.upfronthosting.co.za>
In-reply-to
Content
I had an opportunity to play with a FreeBSD 7.2 box recently.

The diagnosis is simple.  The solution may be less so...

Diagnosis:  FreeBSD still considers POSIX semaphores (sem_open,
sem_close, etc.) to be experimental, so they're not enabled by default
on a standard install.  So the very first call to sem_open, from
SEM_CREATE in semaphore.c (around line 439), produces the Signal 12.

Enabling POSIX semaphores (assuming that they've been built into the
kernel, which they seem to have been by default) is as simple as
executing 'kldload sem' (as root) at a shell prompt.  After I did this,
test_multiprocessing ran and all tests passed.

So the question is what multiprocessing (and test_multiprocessing)
should do when POSIX semaphores aren't available.  I guess the options
are: (1) fail loudly, with an error message telling the user to enable
the POSIX semaphores, or (2) try to use SysV semaphores (which are
supported out of the box) instead.

In the immediate future we should probably at least detect when POSIX
semaphores don't exist, and skip test_multiprocessing in that case.
History
Date User Action Args
2009-11-20 14:02:00mark.dickinsonsetrecipients: + mark.dickinson, db3l, jnoller
2009-11-20 14:01:59mark.dickinsonsetmessageid: <1258725719.98.0.527321479441.issue7272@psf.upfronthosting.co.za>
2009-11-20 14:01:58mark.dickinsonlinkissue7272 messages
2009-11-20 14:01:57mark.dickinsoncreate