chicken-janitors
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-janitors] #1356: weak-locatives references return #f when i


From: Chicken Trac
Subject: Re: [Chicken-janitors] #1356: weak-locatives references return #f when it shouldn't
Date: Thu, 27 Apr 2017 11:40:16 -0000

#1356: weak-locatives references return #f when it shouldn't
-----------------------------------+--------------------
            Reporter:  kristianlm  |      Owner:
                Type:  defect      |     Status:  new
            Priority:  major       |  Milestone:  4.13.0
           Component:  unknown     |    Version:  4.12.0
          Resolution:              |   Keywords:
Estimated difficulty:              |
-----------------------------------+--------------------

Comment (by sjamaan):

 Found the reason: The call chain holds a reference to the thread in which
 a procedure call occurs. {{{C_trace}}} will grab the currently running
 thread from {{{##sys#current-thread}}} (as {{{current_thread_symbol}}} in
 {{{runtime.c}}}).

 So the mere fact that this first thread calls {{{make-condition}}} and
 {{{mutex-lock!}}} causes it to stick around.

 This can be verified in several ways:

 - If you add a procedure call to one of the other threads (instead of just
 returning a bare literal), you'll notice that that thread won't be garbage
 collected either. In the interpreter, a simple change of {{{#f}}} to
 {{{(void)}}} will do. When you compile the program you need something more
 elaborate due to optimisations, or use {{{-O0}}} to avoid that.
 - If you run the application with {{{-:a3}}} (it won't go any lower), the
 trace buffer won't have this reference anymore and you'll see that the
 finalizer is run.
 - If you compile with {{{-d0}}}, the {{{C_trace()}}} calls are omitted and
 the threads will all be cleaned up as you expect.
 - If the program does a lot more to fill up the trace buffer, as you have
 noticed yourself, the thread will eventually drop out of the trace buffer
 and the finalizer can trigger.

 So all in all, I think this isn't a bug: the system works perfectly, it's
 just that there's a reference still holding on to the thread which you
 weren't expecting.

 Having said that, perhaps we can store just the thread's name rather than
 the complete thread object, that would allow us to collect it earlier.

--
Ticket URL: <https://bugs.call-cc.org/ticket/1356#comment:5>
CHICKEN Scheme <https://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]