[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: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
Subject: Re: lib/46147 (mono problem (pthread change result?))
Date: Thu, 8 Mar 2012 20:55:40 -0500
On Fri, 9 Mar 2012 01:50:04 +0000 (UTC)
Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> The following reply was made to PR lib/46147; it has been noted by GNATS.
> From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
> To: gnats-bugs%NetBSD.org@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
Thanks for the details,
Main Index |
Thread Index |