Re: pkg/41893: Should devel/boehm-gc be built with thread support by default?

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

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

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/41893: Should devel/boehm-gc be built with thread support
 by default?
Date: Mon, 30 Dec 2013 02:57:25 -0500

 On Sun, 29 Dec 2013 21:00:01 +0000 (UTC)
 David Holland <dholland-pbugs%netbsd.org@localhost> wrote:
 
 > The following reply was made to PR pkg/41893; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-pbugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: pkg/41893: Should devel/boehm-gc be built with thread support by
 >  default?
 > Date: Sun, 29 Dec 2013 20:58:26 +0000
 > 
 >  Matthew Mondor wrote:
 >   >  So should boehm-gc be built with thread support by default,
 >   >  at least on NetBSD-5+?
 >  
 >  Did we ever reach a conclusion on this? I recall there's been some
 >  discussion since the last comments on this PR were filed (which was
 >  two years ago) but I can't currently find it. :-/
 
 Your memory is right, indeed, a conclusion and consensus was recently
 reached on IRC that there should be two packages, one built with
 threads support, and the other built without threads, i.e. boehm-gc and
 boehm-gc-threads.
 
 There is at least one issue with boehm-gc and threads that I know about
 on NetBSD-6/amd64, which appear to have to do with rwlocks.  When libgc
 attempts to gc-or-grow, it then needs to stop the world, and threads
 using rwlocks (such as those using stdio) behave differently than what
 libgc expects.  Avoiding stdio and rwlocks, thread-enabled ECL with
 thread-enabled boehm-gc appear stable.  Interestingly, the signal sent
 by the stop-world procedure to other threads seems to be received, and
 the signal handler called, in rwlocks-using threads, yet those threads
 appear to then lock spinning on a mutex, if I remember.
 
 I think that the solution of having two packages would be rather
 straightforward to implement; that said, I could not personally put any
 time on it yet, unfortunately.
 
 As for the libgc+threads+rwlocks issue itself, it would be nice to fix
 as well eventually; I have the impression that the bug is more in libgc
 than in libpthread, but I've not looked seriously into it.  Among
 possible workarounds might be to override pthread_rwlock functions
 (i.e. in the case of ECL to build them around ECL's own mutex
 implementation), perhaps.  When I looked at the libgc source I seemed
 to be able to understand pretty much how it works, but the low level
 OS-specific part is extremely messy intertwined with many conditionals;
 that would require more time to debug and/or fix (and possibly looking
 at the results after it passed through the preprocessor).
 
 In my two projects based on ECL, the workaround has been to avoid stdio
 and rwlocks.  Unfortunately, this would not be possible in all cases;
 for instance some libraries used through FFI might require FILE
 handles.  In fact, one weak point in one of those two projects still
 rarely reproduces the issue, because libpcap is used which uses stdio
 fread(3) (eventually I'll probably have to replace libpcap by custom
 reads instead to make the application fully stable, as it requires
 threads, but at this point the application itself is embryonal).
 -- 
 Matt