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 davin
Recipients brandjon, davin, memeplex
Date 2015-09-12.21:50:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1442094609.38.0.191413980395.issue24948@psf.upfronthosting.co.za>
In-reply-to
Content
If I understand your motivations correctly, I'd restate them as:  you want a mechanism for being immediately notified of an exception in a parent process without waiting on any child processes of that parent to finish and furthermore propose this should be the default behavior.

Quick side note:  As the docs explain and as the code you propose modifying in Lib/multiprocessing/process.py shows, a Process is designed to track its live children.  Interrupting or otherwise destroying a parent process's ability to track its children even after experiencing an exception in its target function would not be desirable.

I think we agree that the current behavior you describe is not catastrophic in any sense -- the exception occurs, the process finishes waiting on its children, and that exception bubbles up at the end -- nothing is lost or suppressed.

This becomes a question of when should a calling routine be notified of such an exception (happening in what I was just calling a parent process):  immediately, if we ask for it, or when it's otherwise done?  Different use cases motivate different answers to this question.  The current behavior satisfies many common use cases and  thankfully it is not difficult to implement the other behaviors in your own code.  It can start with a try-except inside the example function 'f' where the except clause's code takes some appropriate action right away rather than waiting on the children, if that is what is desired.

    def f():
        try:
            p = mp.Process(target=g)
            p.start()
            1/0
            p.join()
        except Exception as e:
            # Take action, sound the alarm, call out the guards, notify the BDFL!
            raise e


I'm not sure I see the relation to issue13812 which is concerned with traceback text that was sent to stderr but surprisingly wasn't getting flushed to stderr.  This issue has no such problem with flushes on stderr -- we are not waiting on stderr here, we are waiting on the parent to finish waiting on its children before any traceback gets written to stderr.
History
Date User Action Args
2015-09-12 21:50:09davinsetrecipients: + davin, memeplex, brandjon
2015-09-12 21:50:09davinsetmessageid: <1442094609.38.0.191413980395.issue24948@psf.upfronthosting.co.za>
2015-09-12 21:50:09davinlinkissue24948 messages
2015-09-12 21:50:08davincreate