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 vstinner
Recipients gps, neologix, vstinner
Date 2011-06-25.23:23:05
SpamBayes Score 7.804452e-07
Marked as misclassified No
Message-id <1309044186.09.0.6544119535.issue11870@psf.upfronthosting.co.za>
In-reply-to
Content
+    @unittest.skipIf(sys.platform in ('freebsd4', 'freebsd5', 'freebsd6',
+                     'netbsd5', 'os2emx'), "due to known OS bug")

This skip gives very few information, and it is duplicated for each function. I would prefer a constant of the "broken OSes" with your following comment attached to the constant:

+    # Between fork() and exec(), only async-safe functions are allowed (issues
+    # #12316 and #11870), and fork() from a worker thread is known to trigger
+    # problems with some operating systems: skip problematic tests on platforms
+    # known to behave badly.

Or split the test case into two testcases: one using fork and skipped on broken platforms, one not using fork?

---

> As for test_3_join_in_forked_from_thread, well, it could be more
> or less the same problem. We're really doing something prohibited
> by POSIX, so things might break in unexpected ways.

If the creation of a thread after a fork is reliable on some systems, we should not deny the creation of new threads after a fork. You can replace "creation of new threads" by any other non async-safe function in my previous sentence. Therefore I agree that the good answer to this issue is to skip the test on "broken systems" (or should we call them "POSIX compliant systems?" :-)).
History
Date User Action Args
2011-06-25 23:23:06vstinnersetrecipients: + vstinner, gps, neologix
2011-06-25 23:23:06vstinnersetmessageid: <1309044186.09.0.6544119535.issue11870@psf.upfronthosting.co.za>
2011-06-25 23:23:05vstinnerlinkissue11870 messages
2011-06-25 23:23:05vstinnercreate