Re: multi-threading

Re: multi-threading

[Neil Jerram]

2008/7/6 Henri Häkkinen <henri.hakkinen@pp2.inet.fi>:
> On Sat, 2008-07-05 at 23:34 +0100, Neil Jerram wrote:
>
>> Your program looks OK to me.  There is a known stack overflow problem
>> on some OSs, when just trying to load boot-9.scm, and when libguile is
>> compiled without much optimization.  What OS are you running on?
>> Also, if you could manage to test the same program with the latest
>> release (1.8.5), please do that and let us know the result.
>>
>>          Neil
>
> Thank you for your reply. I resolved the problem. I am using Debian
> Linux server and guile was installed from a Debian package. The problem
> was that it was not compiled with pthreads support. Running '*features*'
> from guile shell did not list "threads". I recompiled guile from sources
> with threads support, and my program went okay. That ERROR: Stack
> overflow was very confusing for using threads in non-threads supported
> guile. I suggest fixing it.

The following is mostly for the record, because I'm not sure if
there's anything specific we can do.  If anyone has any comments or
ideas, please say.

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.

A plausible-sounding solution would be to use calls to pthread_self()
so that we catch any attempt by more than one thread to use Guile.  As
the code stands, however, (it appears that) the whole point of
--without-threads is to completely avoid using the pthreads API; this
is reflected both in the code and in configure.in checks.  So using
pthread_self() would be contrary to that point.

Another possibility would be a global counter, counting the number of
calls to scm_with_guile() that haven't yet completed.  But that
doesn't work either, because

- scm_with_guile() is deliberately designed to cope with being called
by a thread that is already in Guile mode, because there are contexts
where it isn't clear if a thread is already in Guile mode - hence
there are cases where the global counter could validly be >1

- the global counter wouldn't catch the case where one thread left
Guile mode, and then another thread entered it.


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.

Regards,
     Neil

Re: multi-threading

[David Séverin]

Le Fri, 3 Oct 2008 23:29:48 +0100,
"Neil Jerram" <neiljerram@googlemail.com> a écrit :

> ...
> 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.

Yes! :-) I have raised this gdbcr [guile debian bug correction request :-)] a couple
of time in a couple of years [or swffi: scheme wishes for full implementation :-)]

It's hard to work without threads these days, and from an GUI application point of
view, there are numerous situations where the user have 'to wait' for what should be
background work ...

It would be really useful if debian --with-threads would become a guile developer
important objective [to make it work]. I believe it would open a all lot of
possibilities and, maybe, contribute to raise the number of guilers on that
platform.

IMHO
David

Re: multi-threading

[Ludovic Courtès]

Hi,

"Neil Jerram" <neiljerram@googlemail.com> 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'.

Re: multi-threading

[Neil Jerram]

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?

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

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.

If we made --with-threads the default, we could say what you suggest
as part of the doc for --without-threads.

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

Regards,
       Neil

Re: multi-threading

[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.