Hello Andy,
Andy Wingo skribis:
> On Thu 05 Jul 2018 14:27, l...@gnu.org (Ludovic Courtès) writes:
>
>> Hello,
>>
>> Andy Wingo skribis:
>>
>>> The signal thread is a possibility though in that case you'd get a
>>> warning; the signal-handling thread appears in scm_all_threads. Do you
>>> see
On Thu 05 Jul 2018 14:27, l...@gnu.org (Ludovic Courtès) writes:
> Hello,
>
> Andy Wingo skribis:
>
>> The signal thread is a possibility though in that case you'd get a
>> warning; the signal-handling thread appears in scm_all_threads. Do you
>> see a warning? If you do, that is a problem :)
>
Hi,
On Thu 05 Jul 2018 12:05, Mark H Weaver writes:
> However, it's also the case that libgc uses 'pthread_atfork' (where
> available) to arrange to grab the GC allocation as well as the "mark
> locks" in the case where parallel marking is enabled. See
> fork_prepare_proc, fork_parent_proc, and
Hello,
Andy Wingo skribis:
> On Thu 05 Jul 2018 05:33, Mark H Weaver writes:
[...]
>> Another possibility: both the finalization thread and the signal
>> delivery thread call 'scm_without_guile', which calls 'GC_do_blocking',
>> which also temporarily grabs the GC allocation lock before calli
Hi,
Andy Wingo writes:
> On Thu 05 Jul 2018 05:33, Mark H Weaver writes:
>
>>> One problem I’ve noticed is that the child process that
>>> ‘call-with-decompressed-port’ spawns would be stuck trying to get the
>>> allocation lock:
>>>
>>> So it seems quite clear that the thing has the alloc lock
Hello Mark,
Thanks for chiming in!
Mark H Weaver skribis:
> Does libgc spawn threads that run concurrently with user threads? If
> so, that would be news to me. My understanding was that incremental
> marking occurs within GC allocation calls, and marking threads are only
> spawned after all
Hi!
On Thu 05 Jul 2018 05:33, Mark H Weaver writes:
>> One problem I’ve noticed is that the child process that
>> ‘call-with-decompressed-port’ spawns would be stuck trying to get the
>> allocation lock:
>>
>> So it seems quite clear that the thing has the alloc lock taken. I
>> suppose this ca
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> (+Cc: Andy as the ultimate authority for all these things. :-))
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> (let loop ((files files)
>>(n 0))
>> (match files
>> ((file . tail)
>> (call-with-input-file file
>>
(+Cc: Andy as the ultimate authority for all these things. :-))
l...@gnu.org (Ludovic Courtès) skribis:
> (let loop ((files files)
>(n 0))
> (match files
> ((file . tail)
> (call-with-input-file file
>(lambda (port)
> (call-with-decompressed-port 'gzip por
l...@gnu.org (Ludovic Courtès) skribis:
> #0 0x7fbb34bf794d in __GI___pthread_timedjoin_ex
> (threadid=140441961314048, thread_return=thread_return@entry=0x0,
> abstime=abstime@entry=0x0, block=block@entry=true)
> at pthread_join_common.c:89
> #1 0x7fbb34bf773c in __pthread_join (t
Hi Ludo,
> When downloading a number of substitutes, ‘guix substitute’ sometimes
> hangs for me since the switch to glibc 2.27. Anyone else experiencing
> this? It’s relatively frequent for me.
It has never happened to me.
--
Ricardo
Hello Guix!
When downloading a number of substitutes, ‘guix substitute’ sometimes
hangs for me since the switch to glibc 2.27. Anyone else experiencing
this? It’s relatively frequent for me.
The backtrace shows this:
--8<---cut here---start->8---
(gdb) bt
#0
12 matches
Mail list logo
