[pypy-dev] FAQ entry

Yuriy Taraday yorik.sar at gmail.com
Mon Apr 6 16:02:16 CEST 2015


On Mon, Apr 6, 2015 at 4:44 PM Maciej Fijalkowski <fijall at gmail.com> wrote:

> On Mon, Apr 6, 2015 at 3:28 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:
> > On Mon, Apr 6, 2015 at 3:48 PM Maciej Fijalkowski <fijall at gmail.com>
> wrote:
> >>
> >> maybe we should add something along those lines to FAQ
> >>
> >> http://emptysqua.re/blog/pypy-garbage-collection-and-a-deadlock/
> >
> >
> > Can't it be fixed? I see 2 possible solutions here:
> > 1. We can detect deadlock (any lock contention during GC round will
> become
> > deadlock) and bail out of GC round early to try again later or skip
> freeing
> > this object (and mark all objects referenced by it).
> > 2. We can defer all calls to __del__ until after GC round and run them
> in a
> > separate Python thread which would allow them to yield processing to let
> > other threads free some lock.
> >
> > I know that either of these solutions would change semantics a bit, but
> it
> > shouldn't affect user's code.
>
> as you can see from the blog post *any* change does affect user code.


Well, I mean if we let user use locks as expected, it won't affect it in
any bad way.

 Note that finalizers are not called during GC, but at some later

"safer" stage, where all the internals are in a sane state.


It's still a part of GC pause (or how you call it) when GIL is taken and
won't ever be released back.

Not sure how you would do 1, really (a global flag on locks?),


Yes, smth like a global flag that would be set during that stage and
Lock.acquire would check it to see if there's a deadlock. We can at least
throw some exception or warning to make it clearer to user what happened.

2 is something Java does.
>

It seems to be the most sane way to do it. It avoids this special state in
which __del__ code is run.

General FAQ entry should say "avoid __del__ doing any substantial job
> at any cost" I would think, whacking at locks is like lipstick on a
> pig.
>

Yes, #1 would just cover one possible problem with them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150406/1ac4725f/attachment.html>


More information about the pypy-dev mailing list