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

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

The following reply was made to PR lib/46147; it has been noted by GNATS.

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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
 > 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.
 
 Thanks for the details,
 -- 
 Matt