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 tim.peters
Recipients davin, eryksun, neologix, pietvo, pitrou, r.david.murray, sbt, tim.peters
Date 2016-07-14.18:46:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1468521995.19.0.538272459706.issue18966@psf.upfronthosting.co.za>
In-reply-to
Content
About:  "The notion of categorically refusing to let a process end perhaps overreaches in certain situations."  threading.py addressed that all along:  if the programmer _wants_ the process to exit without waiting for a particular threading.Thread, that's fine, they ask the Thread constructor for a "daemon" thread.  Whether a threading.Thread does or doesn't prevent process exit before it's .join()'ed has always been the programmer's choice.  Python never attempted to guess their intent (except for "the main thread", which is necessarily non-daemonic).  That's why it's especially surprising that multiprocessing can silently overrule what had always been an explicit choice about process-exit threading.Thread behavior.

About compatibility, yup, that's potentially painful.  I will note that compability was already broken on Windows with no apparent angst, or subsequent complaints (the program in issue 27508 is an example:  "runs forever" under 3.5.2 but "ends very quickly" under 2.7.11; "runs forever" is what the programmer wanted, matching how they expected non-daemon threading.Threads to work).
History
Date User Action Args
2016-07-14 18:46:35tim.peterssetrecipients: + tim.peters, pitrou, r.david.murray, pietvo, neologix, sbt, eryksun, davin
2016-07-14 18:46:35tim.peterssetmessageid: <1468521995.19.0.538272459706.issue18966@psf.upfronthosting.co.za>
2016-07-14 18:46:35tim.peterslinkissue18966 messages
2016-07-14 18:46:35tim.peterscreate