Re: [PATCH] Efficient Gensym Hack (v2)

[Mark H Weaver]

Andy Wingo <address@hidden> writes:

>> The good news is that it should be possible to fix this (pre-existing)
>> class of problems for 'symbols_lock' in stable-2.0 by changing
>> 'symbol_lookup_assoc_fn' to avoid allocation.
>
> That's not enough.  Adding spine segments, ribs, and associating a
> disappearing link all allocate memory, and those are internal to the
> hash table implementation.

Ouch.  Good point.

> Maybe it's good enough to document this defect in 2.0.  "Don't try to
> string->symbol or symbol->string in a finalizer".

I'd guess that 'symbol->string' is relatively unlikely to happen in a
finalizer (though certainly possible).  Calls to 'scm_from_*_symbol', on
the other hand, are extremely common in C code that uses Guile.  This
seems to me a rather serious heisenbug that users are likely to hit.

Would it be possible to fix stable-2.0 to run finalizers in a separate
thread?

    Thanks,
      Mark