Re: lib/46147 (mono problem (pthread change result?))

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

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
Cc: 
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
 system.
 
 Joerg