[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/46147 (mono problem (pthread change result?))
The following reply was made to PR lib/46147; it has been noted by GNATS.
From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
Subject: Re: lib/46147 (mono problem (pthread change result?))
Date: Fri, 9 Mar 2012 02:47:57 +0100
On Fri, Mar 09, 2012 at 01:20:04AM +0000, Matthew Mondor wrote:
> > According to my testing, this works now. Comments about boehm-gc only
> > working by accident still apply though.
> Do you think that anything using boehm-gc with threads currently faces
> the same problem as well? I use ECL with it, built with threads
> enabled, and although it works pretty well, it's not 100% stable when I
> heavily test multithreaded applications (and that on both Linux and
> NetBSD). There has been some work to reimplement ECL's locking system
> too though, and that's not considered stable either, but I use a custom
> implementation here which is more straightforward.
> But I'd very much like to know if boehm-gc itself is fundamentally
> broken in that area.
boehm-gc needs to find all references to objects on the thread stacks.
For that, it should use pthread_attr_get_np and pthread_attr_getstack on
NetBSD. This provides the bottom of the stack and the size, in combination
with __builtin_frame_address(0), that can precisely identify the stack
content. At the moment it does some guessing based on the stack stack
size, assuming alignment of the stack that isn't guaranteed by the
Main Index |
Thread Index |