[pypy-dev] FAQ entry

[Armin Rigo]

Hi,

On 8 April 2015 at 11:43, Yuriy Taraday <yorik.sar at gmail.com> wrote:
> It's already broken if it's used in multithreaded app. For single-threaded
> apps we can make an exception and keep things running as they are now, i.e.
> keep it single-threaded. This will also prevent unnecessary multithreading
> initialization.

You'd end up with cases where you can have a deadlock in
single-threaded programs that magically goes away if you just add
anywhere the line "thread.start_new_thread(lambda:None, ())"...  But
maybe creating lock objects should be enough to change where
destructors run?  You can't easily have deadlocks without user lock
objects.

Or, if you care about deadlocks, maybe your Python program should
explicitly start it own finalizer thread.  Your
potentially-deadlocking __del__ methods should use a decorator that,
when called, simply puts the actual method into a Queue.Queue which is
consumed by this finalizer thread.  It would be the same, but not
transparent.

I think that the idea of doing it transparently may be interesting,
but it needs some more careful design before we can think about
changing PyPy like that.  (Not that there is *any* idea about the GC
that doesn't require careful design :-)


A bientôt,

Armin.