Heya, On Sun 14 Feb 2010 15:32, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo <wi...@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/
