[M3devel] what is "activation" vs. "thread.T"

[Jay]

What is meant by an "Activation" vs. a "Thread.T"?
Why aren't these just one data structure?
 
Why is there both the global "slots" and the threads are in a circularly linked list?
 
Are there difference between "active" threads, "thread", and "slotted" threads?
Or, an active thread is merely one that hasn't finished running yet, is just waiting around for someone to get its result and drop its reference to is, so it can be garbage collected?
 
These things seem closely bound.
CreateT takes an activation and sets it in the new T.
CreateT always calls AssignSlot.
 
Fork always creates one activation and one T, and always put the activation on the circular linked list.
 
Init only calls CreateT and indirectly creates an activation via InitActivations.
 
Therefore -- I don't see a T ever created without an activation, or vice versa.
 
T contains act.
Act does not contain T.
Activation is connected back to T via an index into the global slots array.
 
T is garbage collected.
Activation is not.
Activation is a thread local (pthread/win32).
T is not.
 
Is it, like, threads have to be objects, garbage collected, to fit an interface, and.. threads need to be thread local..and thread locals are hidden from the garbage collector normally??? So arbitrarily split them in two?
I'm not sure I buy that. If it was true, one of them would be nearly empty, just a way to find the other.
 
 
The above is mostly all/only about pthread threads.
Posix threads have no "activations".
Win32 threads also have an idle list.
 
Maybe "activation" is actually small and just the untraced part, mostly, but a little extra crept in? Or, stuff more stuff in it to lighten the load on the garbage collector? Better to put untraced refs within untraced refs, than to put them within traced refs? Or maybe it is a requirement?
 
Or maybe it has to do with locking levels and when traced vs. untraced refs can be touched? That is, the stack is deliberately in the untraced activation so..?
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Thu, 19 Mar 2009 12:25:12 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] pthreads tls initialization?
>
> Sorry, yes, you are correct that the value NULL will also be NIL. So, setspecific NIL is unnecessary.
>
> In any case, I do think we should just move the handler stack into Activation and pare things back to just the one threadlocal per thread.
>
> On 19 Mar 2009, at 12:02, Jay wrote:
>
> But doesn't pthread_create make it so? (More so, it makes it so on any new threads.)
> Or it that not portable? Or did I misunderstand the opengroup web page? Or other?
> Or, is this because, like, the Modula-3 notion of "NIL" might not match the pthread notion of "NULL"? I don't believe in that extreme level of portability/disbelief/theory, but...
> Unless someone can tell me about such a system.. in which
> void* p = 0;
> printf("%p\n", p);
> memset(&p, 0, sizeof(p));
> printf("%p\n", q);
>
> doesn't print two identical lines.
>
> I know the C standard does not guarantee this, and probably therefore Modula-3 doesn't either, but I've never heard of a system on which this isn't true.
> It seems more theoretical than, say, non-IEEE floating point math (which I believe exists on VAX), or, say, 16 bit integers...
>
> - Jay
>
>
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Thu, 19 Mar 2009 10:22:59 +1100
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] pthreads tls initialization?
>>
>> The setspecific call is to initialize the handler stack to nil. It is
>> needed.
>>
>> On 19 Mar 2009, at 01:33, Jay wrote:
>>
>>>
>>> http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html
>>>
>>>
>>> says that thread locals start as zero, but ThreadPThread.m3 does:
>>>
>>>
>>> PROCEDURE InitHandlers () =
>>> BEGIN
>>> WITH r = pthread_key_create_handlers() DO END;
>>> WITH r = pthread_setspecific_handlers(NIL) DO END;
>>> initHandlers := FALSE;
>>> END InitHandlers;
>>>
>>>
>>> Any reason for that setspecific call?
>>>
>>>
>>> I ask because I think some of this code should just be written in C.
>>> But ideally then, the Win32 code should be too.
>>> So I'm just reading them, and they differ oddly in that pthread
>>> keeps doing like:
>>>
>>>
>>> if not initialized Initialize()
>>>
>>>
>>> and Win32 allocates its thread up front locals via the Modula
>>> initializer.
>>> Maybe pthread_key is very expensive, and avoided in single threaded
>>> apps?
>>> But there aren't any, right, because the runtime creates threads, at
>>> least one for the garbage collector?
>>>
>>>
>>> - Jay
>>
>