Re: multi-threading

[Ludovic Courtès]

Hi,

"Neil Jerram" <address@hidden> writes:

> The scenario here was:
> - Guile configured and built without threads support (because coming
> form Debian, which doesn't do --with-threads).
> - A program which
>   - calls scm_boot_guile() on the main thread
>   - inside the scm_boot_guile(), creates another thread (pthread_create)
>   - in that other thread, do scm_with_guile(thread_main, ...)
>   - in thread_main, call scm_c_eval_string(...).
> - Guile reports a Stack overflow error.
>
> Explanation:
> - When configured without threads, there is only one scm_i_thread
> structure, because Guile assumes that it will only be used on one
> thread.  This structure's "base" field is set, within the
> implementation of scm_boot_guile(), to the base address of the main
> thread.
> - The base address of the other thread will be very different from
> that of the main thread.
> - Stack overflow checking works by subtracting &p from
> scm_i_thread->base, and comparing this to the allowed stack depth
> (where p is some variable on the stack in the function where the check
> is being applied).
> - It is easy for (scm_i_thread->base - &p) to exceed any stack depth
> limit, because scm_i_thread->base and &p point into two different
> stacks.

Hmm, good catch!  I didn't expect such a scenario to lead to disastrous
situations like this.

> In practice, maybe the most useful thing we can do is to encourage
> configuration --with-threads, and in particular to work through
> whatever the reason is why Debian doesn't do this.

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.

Besides, the doc could emphasize that only the main thread can use
Guile-without-threads in a pthread program.

Thanks,
Ludo'.