GNU bug report logs - #26858
Cygwin port of Guile 2.2

Previous Next

To reply to this bug, email your comments to 26858 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Derek Upham <sand <at> blarg.net>
Cc: guile-devel <at> gnu.org, Mike Gran <spk121 <at> yahoo.com>
Subject: Re: Cygwin port of Guile 2.2
Date: Tue, 09 May 2017 21:08:08 +0200

On Wed 03 May 2017 16:21, Derek Upham <sand <at> blarg.net> 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 would be a memory leak too AFAIU.)  Bcc'ing
bug-guile to create a bug for that.

Andy

Message #10 received at 26858 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 26858 <at> debbugs.gnu.org
Subject: Re: bug#26858: Cygwin port of Guile 2.2
Date: Tue, 09 May 2017 15:26:45 -0400

(Reported reassigned to guile)

Andy Wingo wrote:

> Bcc'ing bug-guile to create a bug for that.

FYI: if you use bcc, the system has no idea which package to associate
your bug report with. So you must specify "Package: guile" in the first
line of the body.

Message #13 received at 26858 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Derek Upham <sand <at> blarg.net>
Cc: 26858 <at> debbugs.gnu.org, guile-devel <at> gnu.org
Subject: Re: Cygwin port of Guile 2.2
Date: Mon, 15 May 2017 22:06:27 +0200

Greets,

On Fri 12 May 2017 16:13, Derek Upham <sand <at> blarg.net> writes:

> Andy Wingo <wingo <at> pobox.com> 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
>> bug-guile to create a bug for that.
>
> I noticed that scm_join_thread was calling back into Scheme-land.  Are these statements all correct?
>
> - We are using call-with-new-thread underneath the hood.

Underneath the hood of what? :)

> - call-with-new-thread is documented to return a Scheme object from a
> thunk/handler.  Any underlying pthreads should be implementation
> details.

Correct.  In practice call-with-new-thread will create a pthread but I
can imagine circumstances in which it might (in the future) spawn an
auxiliary pthread for some reason, and I wouldn't want to rule that out.

> - The spawned thread sends the Scheme object to the condition variable
> as soon as the user thunk exits.  Any number of operations can happen
> afterwards; the thread is still running in Scheme-land at this point,
> in call-with-new-thread’s wrapping thunk.
> - join-thread waits on the condition variable only.

These are implementation details.  They are correct but probably the
implementation should change to do the scm_i_pthread_join and we should
guarantee that after the join, the thread is really dead.  This is bug
26858.

> So at the end of join-thread we need to add a call to
> scm_i_pthread_join (which we implement in threads.c) to ensure that
> the pthread is completely gone before that join-thread returns.  Is
> that accurate?

Well... yes, but we have to ensure that we call scm_i_pthread_join at
most once.  I think calling pthread_join twice on a thread is
undefined.  So there are some gnarlies here.  Need to fix this.

> Unfortunately, I think the GC threads are going to end up being
> immovable objects in the path to full process-form support.

You can disable marker threads with the GC_MARKERS environment variable,
and the finalization thread should come and go as needed.  Probably this
is not a blocker from your POV.  Signal handling is probably the most
serious issue; perhaps we can avoid the thread somehow, since we handle
signals asynchronously anyway..

Andy

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.