bug#14511: Unexpected behaviour of scm_gc+sleep/usleep in another thread

[Ludovic Courtès]

Panicz Maciej Godek <address@hidden> skribis:

> 2013/6/4 Ludovic Courtès <address@hidden>
>
>> Panicz Maciej Godek <address@hidden> skribis:
>>
>> > 2013/6/4 Ludovic Courtès <address@hidden>
>> >
>> >> [...]
>> >> I can’t reproduce it with current ‘stable-2.0’ and ‘master’, on
>> >> x86_64-linux-gnu, with libgc 7.2alpha6 (which is ancient).
>> >>
>> >> Could you provide more info about your system and dependency versions
>> >
>> >
>> > i am using the version from ubuntu 12.04 repository
>> >
>> > $ guile --version | grep guile
>> > guile (GNU Guile) 2.0.5-deb+1-1
>>
>> And what version of libgc (the garbage collector)?
>>

[...]

> Version: 1:7.1-8ubuntu0.12.04.1

[...]

>> Could you check whether the problem still occurs with Guile 2.0.9?
>>
>  It does (at least when linked against the same garbage collector)

The documentation of ‘sleep’ is:

  - Scheme Procedure: sleep i
       Wait for the given number of seconds (an integer) or until a signal
       arrives.  The return value is zero if the time elapses or the
       number of seconds remaining otherwise.

I’m pretty sure that if you check its return value, you’ll notice that
it behaves as documented.  Can you confirm?

What happens here is that libgc uses signals for stop-the-world
collections, and (gc) certainly does with the libgc version you’re
using.

‘sleep’ calls select(2), which in your case presumably returns
prematurely with EINTR.  You should be able to confirm this hypothesis
by running Guile with:

  strace -f -e select guile

(Note that the problem doesn’t occur with libgc 7.2, presumably because
it uses a different strategy.)

Thanks,
Ludo’.