Andy Wingo <wi...@pobox.com> 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
