homepage

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 gvanrossum, vstinner, yselivanov
Date 2014年12月05日.09:11:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1417770701.14.0.00871345911493.issue22926@psf.upfronthosting.co.za>
In-reply-to
Content
Ok, here is an updated patch (version 2):
- tests still ensure that the event loop is passed explicitly
- call_soon() & cie now fail if the policy has no event loop set for the current thread (before it only failed if the event loop set in the policy was different than the called event loop)
> I'm not sure that this particular change is a great idea. I kind of liked that unittests ensure that loop is passed everywhere explicitly in asyncio.
I agree, but we can just monkey-patch the _assert_is_current_event_loop() to disable the check even if debug mode. For example, it can be done in test_utils.TestCase.set_event_loop(), no need to modify individual test cases.
> Maybe only in debug mode?
Oh sorry, I forgot to mention that my patch only enhance an existing test, _assert_is_current_event_loop(), which is only done in debug mode.
I'm so happy to have this debug mode, at the beginning Guido didn't want it :-D
> - modify BaseEventLoop._assert_is_current_event_loop() to fail if the thread has an event loop
Oops, the method already fails if the event loop is different than the current event loop of the policy. My patch changes the behaviour when the policy has *no* current event loop.
> In your patch, you should also replace 'except AsserionError' with 'except RuntimeError'.
Ok, that's why we must reject any patch without unit test :-D
> I still think you shouldn't set the thread when the loop is created but
only when run*() is active. (Using call_later() from another thread when
the loop is inactive should not be an error IMO -- there's nothing against
passing a selector instance to another thread as long as only one thread at
a time waits for it.)
Hum, I'm not fully convinced. Technically, it "works" to call call_soon() instead of call_soon_threadsafe() when the event loop is not running yet. But multithreading means race condition. It probably means that in most cases, calling call_soon() would work because the event loop didn't start yet, but in some cases, the event loop may already run depending on the timing.
I prefer to force users to always use call_soon_threadsafe() to avoid bad suprises.
History
Date User Action Args
2014年12月05日 09:11:41vstinnersetrecipients: + vstinner, gvanrossum, yselivanov
2014年12月05日 09:11:41vstinnersetmessageid: <1417770701.14.0.00871345911493.issue22926@psf.upfronthosting.co.za>
2014年12月05日 09:11:41vstinnerlinkissue22926 messages
2014年12月05日 09:11:40vstinnercreate

AltStyle によって変換されたページ (->オリジナル) /