Greets,
On Fri 12 May 2017 16:13, Derek Upham writes:
> Andy Wingo writes:
>
>> scm_join_thread isn't actually implemented in terms of
>> scm_i_pthread_join any more. Probably that's what's going wrong here --
>> and probably that should be fixed to ensure that we actually join the
>> thread.
Andy Wingo writes:
> scm_join_thread isn't actually implemented in terms of
> scm_i_pthread_join any more. Probably that's what's going wrong here --
> and probably that should be fixed to ensure that we actually join the
> thread. (Otherwise it would be a memory leak too AFAIU.) Bcc'ing
> bu
On Wed 03 May 2017 16:21, Derek Upham writes:
> scm_join_thread start
scm_join_thread isn't actually implemented in terms of
scm_i_pthread_join any more. Probably that's what's going wrong here --
and probably that should be fixed to ensure that we actually join the
thread. (Otherwise it wou
On 05/02/2017 08:18 PM, Derek Upham wrote:
> Andy Wingo writes:
>
>> On Mon 01 May 2017 22:48, Derek Upham writes:
>>
>>> Running pthread_join() on a thread only guarantees that the thread has
>>> returned an exit value.
>>
>> Would you mind providing a reference please? It is not that I don't
Andy Wingo writes:
> I think there's an argument that a thread doesn't "terminate" until its
> thread-local key destructors have finished running, and therefore
> pthread_join doesn't return until after the key destructors have run.
> This is my understanding of what happens from reading NPTL. D
On Wed, May 03, 2017 at 11:24:30AM +0200, Andy Wingo wrote:
> On Wed 03 May 2017 05:18, Derek Upham writes:
>
> > Andy Wingo writes:
> >
> >> On Mon 01 May 2017 22:48, Derek Upham writes:
> >>
> >>> Running pthread_join() on a thread only guarantees that the thread has
> >>> returned an exit va
On Wed 03 May 2017 05:18, Derek Upham writes:
> Andy Wingo writes:
>
>> On Mon 01 May 2017 22:48, Derek Upham writes:
>>
>>> Running pthread_join() on a thread only guarantees that the thread has
>>> returned an exit value.
>>
>> Would you mind providing a reference please? It is not that I do
Andy Wingo writes:
> On Mon 01 May 2017 22:48, Derek Upham writes:
>
>> Running pthread_join() on a thread only guarantees that the thread has
>> returned an exit value.
>
> Would you mind providing a reference please? It is not that I don't
> believe you but I think it's important to know whet
On Mon 01 May 2017 22:48, Derek Upham writes:
> Running pthread_join() on a thread only guarantees that the thread has
> returned an exit value.
Would you mind providing a reference please? It is not that I don't
believe you but I think it's important to know whether this is a bug in
Guile or i
Derek Upham writes:
>> I think also that if you are most interested in a system in which
>> primitive-fork plays a large role, then probably you want a Guile
>> without threads (including the GC mark threads). Threads + fork is not
>> a recipe for success :)
>
> Understood. However, saying “prim
Andy Wingo writes:
>> I have found that what actually hangs after a fork are the mutexes
>> supporting the threads: they are kernel-level resources, referenced by
>> ID, and end up being shared between parent and child.
>
> Which ones, precisely?
GDB shows the hanging child process waiting on a
On Fri 14 Apr 2017 15:41, Derek Upham writes:
> There’s the finalizer thread, but there’s also the signal delivery
> thread. The “sigaction” code ensures that signal delivery thread is
> running. And note that “primitive-fork” is supposed to display a
> warning if you are forking with outstandi
Andy Wingo writes:
> I guess the new thing being the finalizer thread? In theory before the
> fork, Guile will stop the finalizer thread. If that's not working, that
> could be it.
>
> Another option would be to disable fork() but only if Guile is built
> with threads. Actually this is probab
On Tue 04 Apr 2017 18:45, "Mike Gran" writes:
> I push a branch that mostly makes Guile 2.2 work on Cygwin.
Neat. LGTM with some nits, with the exception of the "(throw
'unresolved)" patch -- the corresponding catch is in
test-suite/test-suite/lib.scm:344.
> Cygwin's uselocale is broken and ca
> From: "Mike Gran"
> Date: Tue, 04 Apr 2017 09:45:43 -0700
>
> Lastly, Cygwin's fork just doesn't play well with Guile's
> new GC and threading model. Despite a copy of days in the
> guts of it all, I don't understand the specifics of the
> issue. So, in the branch, I disabled forking altogeth
15 matches
Mail list logo
