Re: [Chicken-janitors] #1356: trace buffer unnecessarily holds on to thread objects

[Chicken Trac]

#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.