> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Andreas Raab
> Sent: Monday, February 11, 2002 1:47 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Process local variable and debugging
> 
> If you have as simple a model as Squeak has there is an even easier
(and
> more efficient) way of doing TLS. All you need is some slot in Process
> which will hold an array of "Global Association -> current value".
When
> you switch between processes you exchange the globals with the current
> value of the association, e.g., when you switch _from_ a process you
> restore the old and remember the private values whereas if you switch
> _to_ a process you restore the private and remember the global values.
> Trivial to implement.


That is effectively what I was describing. Except that the scheme I
described is lighter weight in that it lazily configures the per/process
collections.

The scheme I was describing requires (from my own code-base):

1 new <Association> subclass with 2 instance methods (value/value:)

2 class methods on <Process>, and one class-pool variable.

+ making sure the VM uses #value/value: messages to access literal
global-variables (associations).

It requires no code for switching of anything. Which simplifies any
GC/dependency issues with zombie processes and debugging.

-- Dave S. [SmallScript LLC]

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

> 
> The advantage of this scheme is that the cost of using TLS is
associated
> exclusively with the process actually using them. If you switch
between
> processes not using TLS you don't do anything at all - if you switch
> to/from a process making heavy use of it, you pay the price just as
you
> have to.
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On
> > Behalf Of David Simmons
> > Sent: Monday, February 11, 2002 8:15 AM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: RE: Process local variable and debugging
> >
> >
> > 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!
> > >
> >
> >
> >
> >
> 
>