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

[Tony Hosking]

On 19 Mar 2009, at 18:09, Jay wrote:

>
> What is meant by an "Activation"

UNTRACED

> vs. a "Thread.T"?

TRACED

I don't recall the specifics, but it was needed at some point.  Here  
be dragons.  I'll try to reconstruct the reasoning...

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