Sebastian Sastre schrieb:
> 	I'm sure you are able to think about the aplicability of
> Process-Specific Variables. Can you elaborate some examples? I'm pretty sure
> I'm not the only one that is not up to date with that and I think it will
> help to understand the practical consequences of using them facilitating the
> ponderation of it's value.

It's in the wider field of context-oriented/context-aware programming.
Application code (in particular server applications) often have the same
code operating in various contexts, and methods need to find out what
context they operate in.

To give a few examples:
- KomHttpServer includes HttpRequest>>current, which always gives the
   "current" HTTP request. This is set in a process-specific way when
   the request is read from the wire, then all processing methods can
   access it (in the context of a Process), even though they don't
   get the request object as a parameter. This is implemented using the
   DynamicBindings package.
- Seaside offers WACurrentSession>>value, which always provides you
   with the current Seaside session object (related to, but not identical
   with the HTTP request: the session object will store data that
   wasn't transmitted in the last request, but accumulated throughout
   the session). Again, in Seaside, you "always" need to know what
   the "current session" is, but don't want to pass this as a
   parameter.
   At the same time, this can't be a global variable, since multiple
   processes may simulatenously process requests.
- In a transaction environment, there is often a need to know what
   the "current" transaction is.
- In testing, it may be interesting to know whether code is run
   "in" the tester, i.e. whether it was invoked through the test
   runner or not.

These are all examples for dynamic variables: somebody sets it
for a process, then runs some code that only reads it, and then
it should get unset (revert to the previous value).

Process-local variables differ in that a value "persists" even
after the code setting it completes. For an introduction, see

http://en.wikipedia.org/wiki/Thread-local_storage

In Squeak, the only example I could find that may want to use
it is, again, in Seaside:
- WASpotProfiler>>profile: currently reads

	| time value |
	time := Time millisecondsToRun: [value := aBlock value].
	(readings at: Processor activeProcess ifAbsentPut: [OrderedCollection 
new]) add: time.
	^ value

   With process-local variables that could change to

         time := Time millisecondsToRun: [value := aBlock value].
	WAReadings value add: time.
         ^value

   Here, I use the feature that the process-local variables as
   I defined them allow the definition of a default value,
   which would be OrderedCollection new in the case of WAReadings.
   Of course, one would also need a way to gather totals across
   all processes (I'm uncertain why WASpotProfiler collects
   them per-process).

- In VisualWorks, a similar mechanism is available; they use
   process-local variables to record the "current debugger"
   per Process, and to inject values into a process from the
   outside.

- Also in VW, they have per-process UI managers.

- In the GNU C library, thread-local storage is used to reduce
   contention in memory management. Each thread has its own
   memory arena from which memory is allocated, and global
   synchronization is only performed when the arena is exhausted.

- Also in the C library, the value of errno (the last error
   that occurred) is thread-specific. It can't be a dynamic
   variable, since it is set by the callee, and read by the
   caller.

- A random-number generator may store its state in a thread-local
   object, in order to provide a repeatable sequence of pseudo-
   random number on a per-thread basis (rather than having
   other threads interfere by picking numbers out of that sequence).


In reviewing code from other languages, it seems that they often
use thread-local variables as the foundation for implementing
dynamic variables on top of it. I believe there is a use for
both of them, so I included them both.

HTH,
Martin