Hi,
On 8 April 2015 at 13:35, Yuriy Taraday wrote:
> That would be creating new references to self in __del__ which is bad (at
> least docs say so). And after that these references will be gone once again
> and __del__ will be called again.
No, in PyPy it is fine, but indeed it is a problem in C
On Wed, Apr 8, 2015 at 1:57 PM Armin Rigo wrote:
> On 8 April 2015 at 11:43, Yuriy Taraday 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 w
Hi,
On 8 April 2015 at 11:43, Yuriy Taraday 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
> initializati
On Wed, Apr 8, 2015 at 12:02 PM Armin Rigo wrote:
> Hi Yuriy,
>
> On 8 April 2015 at 10:47, Yuriy Taraday wrote:
> > 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 pre
Hi Yuriy,
On 8 April 2015 at 10:47, Yuriy Taraday wrote:
> 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?
For example, because it would break this cla
On Wed, Apr 8, 2015 at 10:16 AM Armin Rigo 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
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 thr
Hi Fijal,
On 7 April 2015 at 20:14, Maciej Fijalkowski wrote:
> Are you sure this is true for the case where object is found inside a
> cycle? (these days, they're run, not sure if in 2.7 or 3.x)
Ah, you're right. There is always the case where objects are
reachable from a cycle (even if they a
On Tue, Apr 7, 2015 at 8:18 PM Armin Rigo wrote:
> Hi Yuriy,
>
> On 7 April 2015 at 16:00, Yuriy Taraday wrote:
> >> We can't even be sure that an actual deadlock situation encountered in
> >> a __del__ is really a deadlock; maybe a different thread will come
> >> along and release that lock soo
On Tue, Apr 7, 2015 at 7:18 PM, Armin Rigo wrote:
> Hi Yuriy,
>
> On 7 April 2015 at 16:00, Yuriy Taraday wrote:
>>> We can't even be sure that an actual deadlock situation encountered in
>>> a __del__ is really a deadlock; maybe a different thread will come
>>> along and release that lock soon..
Hi Yuriy,
On 7 April 2015 at 16:00, Yuriy Taraday wrote:
>> We can't even be sure that an actual deadlock situation encountered in
>> a __del__ is really a deadlock; maybe a different thread will come
>> along and release that lock soon... I think this is a problem that is
>> just as hard as the
Sorry for hijacking thread. I hope I won't hider it too much.
On Mon, Apr 6, 2015 at 10:05 PM Armin Rigo wrote:
> (2) cannot be done in Python without major changes in semantics. User
> code that makes no use of threads, for example, certainly doesn't
> expect to be careful about multithreading
Hi Maciej,
On 6 April 2015 at 21:08, Maciej Fijalkowski wrote:
> My question stands - should we add this short explanation (maybe with
> a link to the blog post) to FAQ as to why you should not use locks in
> dels?
My problem with the blog post is that, after it correctly diagnoses
the problem,
My question stands - should we add this short explanation (maybe with
a link to the blog post) to FAQ as to why you should not use locks in
dels? Or maybe why you should not have advanced logic in dels to start
with.
On Mon, Apr 6, 2015 at 9:05 PM, Armin Rigo wrote:
> Hi Yuriy,
>
> (2) cannot be
Hi Yuriy,
(2) cannot be done in Python without major changes in semantics. User
code that makes no use of threads, for example, certainly doesn't
expect to be careful about multithreading in the __del__ methods.
(1) is hard too. What is hard is to decide when acquiring a lock in a
__del__ is sa
On Mon, Apr 6, 2015 at 4:44 PM Maciej Fijalkowski wrote:
> On Mon, Apr 6, 2015 at 3:28 PM, Yuriy Taraday wrote:
> > On Mon, Apr 6, 2015 at 3:48 PM Maciej Fijalkowski
> wrote:
> >>
> >> maybe we should add something along those lines to FAQ
> >>
> >> http://emptysqua.re/blog/pypy-garbage-collect
On Mon, Apr 6, 2015 at 3:28 PM, Yuriy Taraday wrote:
> On Mon, Apr 6, 2015 at 3:48 PM Maciej Fijalkowski 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 h
On Mon, Apr 6, 2015 at 3:48 PM Maciej Fijalkowski 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 rou
maybe we should add something along those lines to FAQ
http://emptysqua.re/blog/pypy-garbage-collection-and-a-deadlock/
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
19 matches
Mail list logo
