[Ecls-list] thread-specific data
Tobias C. Rittweiler
tcr at freebits.de
Tue Mar 16 10:16:01 UTC 2010
Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> writes:
> On Tue, Mar 16, 2010 at 9:22 AM, Tobias C. Rittweiler <tcr at freebits.de>wrote:
>
>> Yes. Two points here: a) many implementations provide a special variable
>> and a keyword parameter on MAKE-THREAD for default bindings in new
>> threads
>
>
> That happens also with MP:MAKE-PROCESS
> http://ecls.sourceforge.net/new-manual/re21.html
>
>
>> , b) it will create thread-local bindings, but not thread-local
>> data. I.e. the data will be part of the general Lisp heap, and can be
>> freely shared between threads.
>> It has not been implemented yet, but I made the suggestion on SBCL's bug
>> tracker to introduce a THREAD-LOCAL-VALUE special form a la
>> LOAD-TIME-VALUE.
>>
>
> What would be the rationale and specification for such a THREAD-LOCAL-VALUE?
> Aren't special variable bindings enough?
The rationale is to have something like local static in C but being
thread-safe, e.g.
(let ((x (thread-local-value 0)))
#'(lambda ()
(incf x)
...))
depending on the actual semantics of THREAD-LOCAL-VALUE, the following
may in fact be possible too:
#'(lambda ()
(let ((x (thread-local-value 0)))
(incf x)
...))
Perhaps a declaration is indeed better because it does seem to be tied
to bindings (question is whether inherently and whether there's a
plausible use case for not tieing it to bindings) -- and with DX,
there's already a declaration customizing allocation, so both approaches
seem to be compatible to the standard, mindwise.
-T.
More information about the ecl-devel
mailing list