[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: pkgsrc/devel/boehm-gc
Greg Troxel <gdt%ir.bbn.com@localhost> writes:
> [followup changed to tech-pkg, as this is larger in scope than the usual
> pkgsrc-changes discussion]
> Matthew Mondor <mm_lists%pulsar-zone.net@localhost> writes:
>> On Thu, 01 May 2014 20:30:16 -0400
>> Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>>> So given the bug history, it seems that boehm-gc with threads is likely
>>> the normal case, and we need to add a boehm-gc-nothreads package, and
>> Historically in pkgsrc threads were disabled by default for boehm-gc,
>> until very recently. The intent of pkg/41893 was originally to enable
>> threads by default, but then it became evident that some issues existed.
>> On some Linux distributions, it's indeed now enabled by default (i.e.
>> on Ubuntu); but I also could not reproduce the same bugs on Linux when
>> I last tried.
> I realize it's been unthreaded in pkgsrc historically. But I meant that
> in the larger free software world, it seems that the threaded version is
> considered more normal.
> (I see this has been reverted for now, but we still need to figure out
> what to do.)
> So where we are, as I see it:
> threads being enabled is currently dependent on platform. That
> doesn't make sense, and is counter to the pkgsrc way. (It probably
> means that ecl fails on Darwin, but maybe it's broken anyway.)
I don't understand what was the reason to do it in a platform-dependent way.
> It seems we have a situation where many uses of libgc need or desire
> threads, perhaps more than half (but it's not clear), but there is at
> least one known case (ecl) where that causes trouble. But, the most
> prominent user of ecl is using it threaded and avoiding the bug -- so
> the idea that boehm-gc should not be built threaded because of ecl
> does not have a lot of support. The PR does not contain other
I'm using it unthreaded exactly because I've never seen threaded version
in functional state. Thus it is the opposite way actually.
> The other question is who is going to do what work, and in what stages.
> So I'd say that if anyone wants to create a boehm-gc-nothreads package
> (without requiring it to not conflict), it's then ok to flip boehm-gc
> back to threads, and any depending packages that have trouble with that
> can then just move to the nothreads version. That will result in being
> able to install either the threaded or the nonthreaded version. This is
> not really a regression, because right now packages can't be built with
> thread support, so we essentially have a forced option. Having two that
> couldn't be installed together would be more flexible than what we have
> now, and more useful for binary package users.
> Then, if someone wants to change the nothreads version to not conflict,
> that would be great. But I don't think we should hold up incremental
> progress based on that not being done.
I'm testing the state of threads support with the new release,
but I cannot do it instantly.
Main Index |
Thread Index |