Process local variable and debugging

Andreas Raab Andreas.Raab at gmx.de
Mon Feb 11 09:47:05 UTC 2002


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.

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





More information about the Squeak-dev mailing list