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 aeros
Recipients aeros, asvetlov, vstinner, yselivanov
Date 2019-10-25.23:36:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I think FastChildWatcher and SafeChildWatcher should go, ThreadedChildWatcher should be kept default and MultiLoopChildWatcher is an option where ThreadedChildWatcher is not satisfactory.

Okay, I think I can understand the reasoning here. Do you think that FastChildWatcher and SafeChildWatcher could be deprecated starting in 3.9 and removed in 3.11? If so, I'd be glad to start working on adding the deprecation warnings and the 3.9 Whats New entries.

> MultiLoopChildWatcher problems can and should be fixed; there is nothing bad in the idea but slightly imperfect implementation.

Yeah my largest concern was just that the current issues seem especially complex to fix and I interpreted your previous comment as "I'd like to deprecate all the process watchers in the near future". Thus, it seemed to make sense to me that we could start removing them rather than sinking time into fixing something that might be removed soon. 

By "slightly imperfect implementation", do you have any ideas for particularly imperfect parts of it that could use improvement? 

I feel that I've developed a decent understanding of the implementation for ThreadedChildWatcher, but after looking at the race conditions for MultiLoopChildWatcher in, I'll admit that I felt a bit lost for where to find a solution. Primarily because my understanding of the signal module is quite limited in comparison to others; it's not an area that I've strongly focused on.
Date User Action Args
2019-10-25 23:36:40aerossetrecipients: + aeros, vstinner, asvetlov, yselivanov
2019-10-25 23:36:40aerossetmessageid: <>
2019-10-25 23:36:40aeroslinkissue38591 messages
2019-10-25 23:36:39aeroscreate