Re: Fluids

[Andy Wingo <wingo@pobox.com>]

Heya,

On Sun 14 Feb 2010 15:32, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> But you can't / shouldn't make a new fluid every time you enter a
>> `catch', because currently fluids are never garbage collected! We really
>> need to fix this. I think it's a 1.9 regression.
>
> Indeed.  We should use a weak vector or some such instead of the current
> scm_gc_malloc’d array.
>
>> To do so effectively, I think you'd need to make fluid objects store
>> their values directly, so that the GC doesn't have to go through hoops
>> to know that they're collectable. Ideally they would get their values
>> via pthread_getspecific; but that would defeat some bits of ours about
>> "dynamic states" (not a very useful concept IMO), and the GC would need
>> help. Actually it would be nice if libgc supported thread-local
>> allocations. (Does it?)
>
> I think dynamically allocating thread-local storage can only be done
> with pthread_key_create ().  Libgc knows how to scan pthread keys.  So
> we could have fluids be wrappers around pthread keys and fluid-ref would
> boil down to pthread_getspecific ().  Then we wouldn’t even need the
> fluid number hack.
>
> Is it what you had in mind?

Yes, this is what I had in mind; I was not aware that libgc could scan
thread-specific variables. This is great news, I think.

My only qualm regards the number of potential pthread_key variables. My
current emacs session has about 15K functions and 7K variables. Does the
pthread_key mechanism scale well to this number of thread-local
variables?

Also we would probably still need a weak vector of all fluids, to
support dynamic states. But this is well-supported by libgc.

Andy
-- 
http://wingolog.org/