Hi Tim,

No surprise, but thread-local-store variables were designed as part of
the original AOS-1991-Platform VM's model. Thus they were in QKS
Smalltalk, and they are in SmallScript. Ok, so what?

The so what is that they are very easy to implement. Switching to
classic Smalltalk parlance requires some semantic calibration. So here
goes:

<calibration>
A classic Smalltalk <Process> is a "green thread".

SmallScript's threading model builds on native OS pre-emptively
scheduled SMP threads. Where fibers (switchable stacks) on top of a
native OS thread's can be used to provide "green threads". Noting that
something like green threads [a stack section object] is required to
implement continuations. Given smp-threads and extensive OS
thread-local-store settings where native frames are interweaved with
vm-method frames, the mechanism requires that a fiber-like-continuation
object correspond to a specific smp-thread.
</calibration>

Thread local state is crucial feature for many types of services. I used
it heavily in the designs of the Mac and Win32 versions of QKS
Smalltalk. It greatly simplifies services like globalization,
multi-thread UI, and a wide range of server applications.

How can you implement it in classic Smalltalk? 

--------
Solution
--------
a) Create a subclass of <Association> where the <value> field contains
either <nil> or an <Index>.

b) Add a inst-var field (slot) to <Process> called TLSStore. Then add
methods for getter/setter operations based on a slot index. Then
allocate an OrderedCollection instance collection, on-demand, to provide
the store. The getter will return <nil> if there is no store for the
receiver process, or it will return <nil> if the store has fewer indexed
slots than the provided tls-index-key. For a setter operation, it will
ensure that the TLSStore is allocated for the process. It will ensure
that TLSStore has at least as many indexed slots as the tls-index-key.
It will then store the provide put: value into the tls-index-key slot of
the TLSStore <OrderedCollection> instance.

c) Add synchronous class methods to <Process> to globally manage and
allocate TLS slot indices. This should be relatively easy to figure out
what is needed given my comments in (b) and elsewhere.

d) In the <TLSAssociation> class, write the getter/setter value methods
to

d.1) Check to see if their <value> field is <nil>. If so, request the
<Process> class to assign a TLS slot index and record it as the <value>.

d.2) Query the current process for TLSStore value (getter/setter) at the
association's tls <value> index.

===========

Once you have done that, they you should be able to use
<TLSAssociations> in the <SystemDictionary> or an equivalent mechanism
in whatever namespace system you have. This presumes that the opcodes
(bytecodes) for accessing associations will be smart enough to send
#value messages to the association rather than just accessing the
<value> slot. With a jitter it can be made even faster and message
invocations can be optimized away.

-- Dave S. [SmallScript Corp]

SmallScript for the AOS & .NET Platforms
David.Simmons at SmallScript.com | http://www.smallscript.org

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Tim Rowledge
> Sent: Wednesday, February 06, 2002 4:36 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Process local variable and debugging
> 
> Here's an intersting little problem.
> 
> I'm trying to build a swiki.net application and having a lot of
problem
> when debugging. The problem is a side effect of how swiki.net keeps
> track of the http request and other stuff for each process that it
> spawns. The intention is to use 'globals' attached to each process
> (I'll let Stephen explain if he wants to) - which works reasonably
well
> although it always makes me a bit nervous to mess with the structure
of
> Processes.
> 
> The problem comes when debugging. The code to set or get the pseudo
> globals involves incantations like
> 	Processor activeProcess foobleAt: wibble
> and when debugging the Processor activeProces is.... the debugger
> process. Bang, end of debugging run :-(
> 
> There are three possible solutions I can see.
> a) fix the debugger to work around this. It seems like it might be a
> good idea to get the process being debugged when your code says
> Processor activeProcess, but on the other hand it might be confusing
in
> some cases. This might be a situation where an integrated
environmentis
> a bit of a liability.
> b) make a way to have 'thread local variables' that doesn't raise the
> problem. Namespaces of some sort?
> c) some other way of provding the same functionality in a different
> manner entirely. ComSwiki does this by explcitly passing the
> httprequest(etc) to all code involved.
> 
> Helpful suggestions welcomed.
> 
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Fractured Idiom:- IDIOS AMIGOS - We're wild and crazy guys!
>