guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bdw-gc includes in libguile.h


From: Ludovic Courtès
Subject: Re: bdw-gc includes in libguile.h
Date: Mon, 28 Mar 2011 21:22:13 +0200
User-agent: Gnus/5.110013 (No Gnus v0.13) Emacs/23.3 (gnu/linux)

Hello!

Andy Wingo <address@hidden> writes:

>>> Sure.  Sorry for the precipitous action.  That said, this bug has been
>>> open since September:  https://savannah.gnu.org/bugs/?32436
>>
>> Oh indeed, I hadn’t realized there’s a connection; still...
>
> Do you have any thoughts on that bug,

The problem is that libgc ends up being initialized behind our back upon
the first libgc-redirected ‘pthread_create’ call.

Hans Boehm suggested [0] two solutions:

  1. Disable pthread redirects and instead register threads explicitly
     (in ‘scm_with_guile’).

  2. Initialize libgc in a constructor.

I was leaning towards (2), because this way we’d be in control, and in
particular we’d have GC_all_interior_pointers = 0.  It would only work
on GCC/ELF platforms, and only if libgc wasn’t already initialized (for
instance if Guile is used in an application that already uses libgc on
its own)—but that really covers 90% of our use cases.

I understand you’re in favor of (1).  This would give the same behavior
as in 1.8[*] while being less hackish than (2).  However, it’s only
applicable to 2.1.

Thus, I think we could go with (2) in 2.0 (on platforms where
constructors are available), and with (1) in 2.2.

[0] http://thread.gmane.org/gmane.lisp.guile.bugs/5340

[*] The behavior in 1.8 is that the non-guile-mode stack isn’t scanned.
    I would find it less error-prone if all the stacks were scanned by
    default, but it’s not that important either.

> or the recent threads.c patches?

Yes, see <address@hidden>.  :-)

(There are a couple of build failures on Hydra since these patches, but
we’ll see that after.)

Thanks!

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]