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 davin, eryksun, neologix, pietvo, pitrou, sbt, tim.peters
Date 2016-07-14.15:15:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1468509315.43.0.2904238565.issue18966@psf.upfronthosting.co.za>
In-reply-to
Content
Tim:  Totally agreed about threading.Thread not being a POSIX thread.  It was not my intent to suggest that they were equivalent -- apologies for the confusion.

Instead I was attempting to describe a mentality of processes and their common behavior across multiple platforms at termination.  The behavior of child processes via multiprocessing currently appears to follow this common mentality of signal the threads then exit quickly.  (To avoid confusion, I am making an observation here.)

Whereas threading.Thread is attempting to provide something homogeneous across platforms, achieving a similar goal in multiprocessing.Process is complicated by the concepts of fork vs. spawn and their availability on various OSes (a source of real confusion for some).  This further opens the question of what should the mentality be for multiprocessing.Process?  The notion that a process can die in such a way that not all of its threads were given time to clean up does not strike me as a foreign concept.  The notion that a threading.Thread should always be (or at least be attempted to be) joined makes sense.  The notion of categorically refusing to let a process end perhaps overreaches in certain situations.

I believe the more general solution exists in offering atexit handlers on multiprocessing.Process.
History
Date User Action Args
2016-07-14 15:15:15davinsetrecipients: + davin, tim.peters, pitrou, pietvo, neologix, sbt, eryksun
2016-07-14 15:15:15davinsetmessageid: <1468509315.43.0.2904238565.issue18966@psf.upfronthosting.co.za>
2016-07-14 15:15:15davinlinkissue18966 messages
2016-07-14 15:15:15davincreate