GNU bug report logs -
#14511
Unexpected behaviour of scm_gc+sleep/usleep in another thread
Previous Next
Full log
Message #20 received at 14511 <at> debbugs.gnu.org (full text, mbox):
Panicz Maciej Godek <godek.maciek <at> gmail.com> skribis:
> 2013/6/4 Ludovic Courtès <ludo <at> gnu.org>
>
>> Panicz Maciej Godek <godek.maciek <at> gmail.com> skribis:
>>
>> > 2013/6/4 Ludovic Courtès <ludo <at> gnu.org>
>> >
>> >> [...]
>> >> 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’.
This bug report was last modified 12 years and 66 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.