Message206655
| Author |
sbt |
| Recipients |
Olivier.Grisel, brett.cannon, christian.heimes, eric.snow, larry, ncoghlan, pitrou, python-dev, sbt, zach.ware |
| Date |
2013年12月20日.00:38:02 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<52B39168.7050105@gmail.com> |
| In-reply-to |
<CADiSq7eP_avr4j+yZORC=U7HDpCpxmRqXTFUf+4RBuCFNxt6BA@mail.gmail.com> |
| Content |
On 19/12/2013 10:00 pm, Nick Coghlan wrote:
> I think that needs to be fixed on the multiprocessing side rather than just
> in the tests - we shouldn't create a concrete context for a start method
> that isn't going to work on that platform. Finding that kind of discrepancy
> was part of my rationale for basing the skips on the available contexts
> (although my main motivation was simplicity).
>
> There may also be docs implications in describing which methods are
> supported on different platforms (although I haven't looked at how that is
> currently documented).
>
If by "concrete context" you mean _concrete_contexts['forkserver'], then
that is supposed to be private. If you write
ctx = multiprocessing.get_context('forkserver')
then this will raise ValueError if the forkserver method is not
available. You can also use
'forkserver' in multiprocessing.get_all_start_methods()
to check if it is available. |
|