On Wed, Apr 8, 2015 at 10:16 AM Armin Rigo <ar...@tunes.org> wrote: > Hi Yuriy, > > It seems that now you've understood the problems, so please re-read my > previous answers :-) > > In particular, I try to give a situation where even what looks like a > deadlock might not be one (because any thread can release any lock), > and why we can't always run finalizers in a separate thread (because > simple non-multithreaded programs don't expect concurrency when > running dels). >
I see problem with solution #1 since deadlock is hard to detect. It actually is a workaround, so it won't work all the time and it's not a prefered solution. I still don't see problem with solution #2. I've been sent a link [0] to a post that shows that signals and finalizers are "unexpected concurrency" anyway. Furthermore even in multithreaded app we can't predict which thread will end up executing them. So my argument is: why not make it clear that __del__ will run in a separate thread instead of trying to pretend that it's something more predictable than that? [0] https://wingolog.org/archives/2012/02/16/unexpected-concurrency
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
