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 rhettinger
Recipients JohanAR, davin, itamarst, rhettinger, sbt, tim.peters, zzzeek
Date 2016-09-09.18:38:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473446333.63.0.654592044643.issue14976@psf.upfronthosting.co.za>
In-reply-to
Content
Guido opposes having us going down the path of using an RLock and altering the queue module to cope with reentrancy. 

In the case of mixing signals with threads, we all agree with Johan Aires Rastén that "using locks with interrupts is in general a very difficult problem and not limited to Python", nor is it even limited to the queue module.  

I believe that the usual technique for mixing signals and threads is to have the signal handler do the minimal work necessary to record the event without interacting with the rest of the program.  Later, another thread can act on the recorded signal but can do so with normal use of locks so that code invariants are not violated.  This design makes reasoning about the program more tractable.
History
Date User Action Args
2016-09-09 18:38:53rhettingersetrecipients: + rhettinger, tim.peters, zzzeek, sbt, JohanAR, itamarst, davin
2016-09-09 18:38:53rhettingersetmessageid: <1473446333.63.0.654592044643.issue14976@psf.upfronthosting.co.za>
2016-09-09 18:38:53rhettingerlinkissue14976 messages
2016-09-09 18:38:53rhettingercreate