[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-janitors] #1356: trace buffer unnecessarily holds on to thr
From: |
Chicken Trac |
Subject: |
Re: [Chicken-janitors] #1356: trace buffer unnecessarily holds on to thread objects |
Date: |
Fri, 27 Oct 2017 20:01:40 -0000 |
#1356: trace buffer unnecessarily holds on to thread objects
-----------------------------------+--------------------
Reporter: kristianlm | Owner:
Type: defect | Status: new
Priority: minor | Milestone: 5.0
Component: unknown | Version: 4.12.0
Resolution: | Keywords:
Estimated difficulty: medium |
-----------------------------------+--------------------
Comment (by sjamaan):
Replying to [comment:10 felix]:
> Ugh. No, let's not make the GC responsible for that as well, it already
has enough special cases as it is.
To get rid of the special case we could pre-allocate a weak locative per
trace buffer entry and store the thread in there. Locatives are already
handled correctly.
> I think we agree that no user code uses the thread, and we only use it
for identity checking. Why not simply add a fixnum id to each thread and
use that for identifcation, fed by a global continuously increasing
counter?
That would require adding an additional slot to the thread, right? If
it's always a fixnum that makes me a bit hesitant regarding wraparound
(let's say you're quickly creating lots and lots of threads but one is
keeping around for longer than all the rest: eventually you'll wrap around
and clobber them), or we'd need to use bignums and create ever-increasing
numbers.
It's probably not a huge issue, but I'd prefer something we know is
stable, like creating an additional gensym per thread, instead. Those are
properly garbage collected and guaranteed to be unique, even if the fixnum
counter wraps around and we start generating names we've already seen.
--
Ticket URL: <https://bugs.call-cc.org/ticket/1356#comment:11>
CHICKEN Scheme <https://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.