Re: multi-threading

[ludo@gnu.org (Ludovic Courtès)]

Hi,

"Neil Jerram" <neiljerram@googlemail.com> writes:

> On 06/10/2008, Ludovic Courtès <ludo@gnu.org> wrote:
>>
>> Surely.  AFAIUI, the reason why Debian doesn't do this is that, (1) part
>>  of the test suite used to fail --with-threads, and (2) when the problem
>>  eventually disappeared, people noticed that Guile --with and
>>  --without-threads aren't ABI-compatible, so Debian has to stick to
>>  --without-threads for 1.8's lifetime.
>
> Do you know the details of the ABI compatibility issue?

We'd have to dig the archive for additional details, but a typical
example is `scm_cell ()', which is inlined and refers to
`scm_i_freelist', which is either a `pthread_key_t' or an
`scm_i_pthread_key_t' from "null-threads.h", depending on whether we're
using threads; in one case `pthread_getspecific ()' is used, in the
other the value is directly accessed.

> The problem is that there's no 'hook' to associate this doc with.  We
> can't say 'if you do so-and-so, take care to note that only the main
> thread can use Guile', because there is no so-and-so - because
> --without-threads is the default.

The default is `--with-threads'.  But yes, I don't know where this could
fit into the doc.

> So I think we should do that - but preferably after solving the ABI issue first.

I'm not sure we can really "solve it".

We could solve it by not having any macro or inline function referring
to thread-local storage, but there may be a performance penalty[*].
We'd also need to not have any public structure containing
`scm_i_pthread_*' objects, in particular the `scm_i_thread' structure.

Thanks,
Ludo'.

[*] BTW, we may eventually want to use the compiler's TLS support, via
    the `__thread' storage qualifier, which would be yet another barrier
    against.