[M3devel] thread calls on non-modula3 threads, win32 vs. posix

[Tony Hosking]

We don't need the checks.  If someone calls from native threads to M3 threads they are programming "UNSAFE"ly anyway, and will have to pay the piper.  We could consider an UNSAFE interface that allows native threads to register themselves for GC, etc.  But this would only be for super-hackers.

On 26 Sep 2010, at 09:59, Jay K wrote:

> 
> Understood -- that is seemingly the point of the Win32 checks. Should they be present on Posix then too?
> 
> Merely hitting "TRY" I expect would access violate.
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Sun, 26 Sep 2010 09:56:29 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix
>> 
>> In general that would be dangerous. If it is a thread not created by Modula-3 Thread.Fork then how will we have the machinery to stop it for GC so its roots can be scanned. In principle, native threads are untraced, whereas M3 threads are traced. Untraced things are not allowed to refer to traced things.
>> 
>> On 26 Sep 2010, at 09:51, Jay K wrote:
>> 
>>> 
>>> What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread?
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sun, 26 Sep 2010 09:13:09 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix
>>>> 
>>>> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right?
>>>> 
>>>> On 26 Sep 2010, at 08:21, Jay K wrote:
>>>> 
>>>>> 
>>>>> I think it is problematic in both.
>>>>> If I understand you.
>>>>> 
>>>>> 
>>>>> The thread locals could be allocated on-demand which might
>>>>> address some situations. Though that can also fail.
>>>>> 
>>>>> 
>>>>> A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach).
>>>>> That even allows you to fail (due to low memory).
>>>>> However that doesn't work as well as one might hope.
>>>>> In particular, any number of threads can be created before a particular .dll is loaded.
>>>>> And a .dll can be unloaded while the threads still exist -- making also thread detach
>>>>> not so ideal for freeing. What you have to do is:
>>>>> - be willing to allocate on demand
>>>>> - have some story for failure
>>>>> - track all the thread locals through a global (!) and free them in thread/process detach
>>>>> (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess;
>>>>> there is a parameter that distinguishes them; best to do nothing, quickly in
>>>>> the ExitProcess).
>>>>> 
>>>>> 
>>>>> Best really really really really best to avoid thread locals.
>>>>> But that is probably impossible.
>>>>> 
>>>>> 
>>>>> Cygwin does wacky stuff where it puts its thread locals at the top of the stack.
>>>>> Which doesn't solve the problems.
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Sat, 25 Sep 2010 10:32:21 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix
>>>>>> 
>>>>>> Is it ok in the WIn32 implementation for the thread to be native.
>>>>>> I think it is ok for pthread.
>>>>>> 
>>>>>> On 25 Sep 2010, at 05:35, Jay K wrote:
>>>>>> 
>>>>>>> 
>>>>>>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} =
>>>>>>> (* LL = m *)
>>>>>>> VAR self := GetActivation();
>>>>>>> BEGIN
>>>>>>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END;
>>>>>>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END;
>>>>>>> XWait(m, c, self, alertable := TRUE);
>>>>>>> END AlertWait;
>>>>>>> 
>>>>>>> 
>>>>>>> The pthread code doesn't have the check for NIL and call to Die.
>>>>>>> Nor for that matter, the uses of ThreadDebug -- which I added.
>>>>>>> 
>>>>>>> I think these should be more similar.
>>>>>>> 
>>>>>>> What I was really wondering about, again, is more common code between Win32 and Posix
>>>>>>> in the thread code...
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>