David,

> 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.

Agreed. The reason why I like the other scheme is that it allows you for
some processes to see the variable as "global" and for others as
thread-local. I guess one might argue about the usefulness of this but
at times it's been exactly what I needed ;-)

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 12:59 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Process local variable and debugging
> 
> 
> > -----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!
> > > >
> > >
> > >
> > >
> > >
> > 
> > 
> 
> 
>