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 Ivan.Pozdeev
Recipients Ivan.Pozdeev, gvanrossum, serhiy.storchaka, terry.reedy
Date 2018-05-04.01:09:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1525396170.43.0.682650639539.issue33412@psf.upfronthosting.co.za>
In-reply-to
Content
> Another possibility is for stop() to change conditions so that 'self.target.event_generate(c)' fails with an exception

Could you elaborate? Since there're no docs on event_generate(), I can't look up how to make it "fail with an exception" without actually posting an event.


> The only problem is that the first t.join() hangs because of a thread deadlock bug.  t.join() blocks until t.run exits.  t.run does not exit until the last event_generate, with running=False, returns.  But that blocks until dummy_handler runs.
> I suppose there is a teeny possibility that 'running' could be flipped between the test and the call.  Can that be prevented with a lock?

The idea is to let the worker threads finish their work, not terminate them forcibly.
So the real problem is that stop() blocks the event loop.
It should rather run asynchronously, wait for threads, then trigger `self.root.destroy()` in the main thread... somehow.
History
Date User Action Args
2018-05-04 01:09:30Ivan.Pozdeevsetrecipients: + Ivan.Pozdeev, gvanrossum, terry.reedy, serhiy.storchaka
2018-05-04 01:09:30Ivan.Pozdeevsetmessageid: <1525396170.43.0.682650639539.issue33412@psf.upfronthosting.co.za>
2018-05-04 01:09:30Ivan.Pozdeevlinkissue33412 messages
2018-05-04 01:09:29Ivan.Pozdeevcreate