Re: multi-threading

[Ludovic Courtès]

Hi,

"Neil Jerram" <address@hidden> writes:

> On 06/10/2008, Ludovic Courtès <address@hidden> 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.