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

[David Holland <dholland-pbugs%netbsd.org@localhost>]

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: Sat, 5 Nov 2011 13:52:24 +0000

 On Sun, Aug 28, 2011 at 03:20:03PM +0000, Matthew Mondor wrote:
  >  How about this?  recht (the previous maintainer) retired since.
  >  
  >  Another possibility would be to have separate boehm-gc and
  >  boehm-gc-threads package, and have ECL depend on boehm-gc-threads via
  >  buildlink.
  >
  >  It would also be possible to tell ECL to build and embed its own
  >  boehm-gc, which is part of the tree, although this duplicates things a
  >  little in RAM.  Is it a valid concern?
 
 The primary concern is that if a vulnerability appears in the package,
 someone has to remember where the extra private copies are and mark
 those packages vulnerable too... and then someone has to apply the
 fixes. This is usually a bad idea, so we like to not use included
 private copies of things.
 
  >  Yet we since force pthread support for everything that uses dlopen(3),
  >  so why not also enable the current thread option by default on
  >  netbsd-5+ and Linux? (boehm-gc doesn't use DLFCN(3), though).
 
 Well, the concern I'd have is that thread support may add a lot of
 overhead. Threaded garbage collection is painful enough in general
 that people go to substantial lengths to avoid it on purpose; I don't
 know to what extent this applies to boehm-gc's thread support.
 
 If there's not a significant problem, then we should enable it by
 default, as non-threaded/single-core environments are not the future
 or even at this point the present.
 
 If there is a problem, a separate package is probably the way to go;
 however, I'd go so far as to say the default package should be
 threaded and the other package should be "boehm-gc-unthreaded".
 
 As to whether there's a problem... that's the sort of thing we have
 package maintainers to know about. I have no idea. If you'd be willing
 to look into it, which hopefully by now should require only digging
 around and not actually benchmarking things, we can probably move
 forward on this...
 
  >  Alternatively, would it be possible for the ECL package, if built with
  >  the threaded option, to also tell its dependency, of not already
  >  present (boehm-gc) to also build with threads support?  This is not
  >  perfect though, as boehm-gc might already have been built.  In which
  >  case, perhaps that building ECL with threads should fail with an error,
  >  unless using an option to tell it to embed its own?  (or, it actually
  >  could enable an option automatically in this case to build its own)?
 
 This sort of thing doesn't really work and probably isn't really a
 good idea...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost