On Dec 29, 2010, at 12:49 PM, Martin v. Löwis wrote:
If the functionality is not supported then users get an import error
(within multiprocessing). However, RDM's understanding is correct,
and
the test is creating more than supported.
Hmm. The tests do the absolute minimum stuff that exercises the code;
doing anything less, and they would be useless. Of course, one may
wonder why test_first_completed manages to create 41 SemLock objects,
when all it tries to do is two future calls.
I actually think that my tests may be overdone - in order to probe for
specific race conditions they use a lot of locks to force calls to
complete in a specific order.
I'm thinking about pairing the tests down to only demonstrate basic
correctness. This should fix the tests on FreeBSD and Windows. Then,
when Python 3.2 is released, I can gradually introduce more
comprehensive tests while ensuring that I keep the buildbots green on
all supported platforms.
Thoughts?
Cheers,
Brian
So if the minimal test case fails, I'd claim that the module doesn't
work on FreeBSD, period. ISTM that Posix IPC is just not a feasible
approach to do IPC synchronization on FreeBSD, so it's better to say
that multiprocessing is not supported on FreeBSD (until SysV IPC is
getting used, hoping that this will fare better).
Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/brian%40sweetapp.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
