[M3devel] [M3commit] CVS Update: cm3

[Jay]

cm3 -DNOPTHREAD compiles m3core for user threads.
 
 
I /sort of/ (almost) haven't removed anything.
I did remove PPC_LINUX stuff.
In new platforms (openbsd, {amd64,sparc}_linux, cygwin),
I might have initially added partial support for user threads,
never complete, tested, working support, and then removed it.
 
 
User threads are broken because PushEFrame uses uninitialized NULL self.
PushEFrame is always called before ThreadF__Init (which initializes
self), but the other two threading libraries (which don't have "self" at all)
initialize on demand what they need in PushEFrame (the thread local handler stack).
 
 
I think self/Thread.T needs to be a traced ref, instead of an object,
so the initial value can be to a preallocated static/global.
I'm not sure of the language here.
"object" seems to deprive you of the "value type".
Whereas refs do not.
 
 
I tried allocating self on demand in PushEFrame but that didn't work.
It ended up back in PushEFrame. I tried more tactics after that, but then
gave up.
 
 
Or move the handle stack out of Thread.T and into a separate global like it was.
 
 
Either change would not affect pthreads or NT threads.
 
 
I would like to see how much I can whittle down m3core of platform-specific stuff,
and then maybe see about adding user thread support for the platforms that never had it.
 
 
I'll add I386_SOLARIS soon, and don't want to duplicate a "large" directory of
files as part of that. I really dislike the multiplicity of such a system.
 
 
I have another chunk of m3core about to go though, for systems that don't have user threads.
Maybe not one that is worthwhile.
 
 
I'm still not much of a believer in user threads.
Essentially I have always had kernel threads, with a processor-portable
interface, and one machine-wide scheduler..seems good..
 
 
Every thread mechanism needs its own locking mechanism, which won't
interace with any other thread or locking mechanism.
 
 
Kind of like picking a C compiler or library -- you want there to be
just one obvious choice per-platform and have everyone use it, so that
there is interop and better overall scheduling.
 
 
You know..Modula-3 I think has problems when the executable doesn't
use the Modula-3 runtime and/or when threads are created outside the runtime,
at then run Modula-3 code. That seems unfortunate.
I /should/ be able to write a "plugin .dll" in Modula-3 and have it loaded
by a C or C++ application, and have garbage collection work.
 
 
Win32 is also kind of wonky here, in that it has "fibers".
Fibers are like swapcontext, plus the stack allocation is handled for you.
Anyone using them has to implement their own scheduler and their own locking mechanisms.
Win32 critical sections, mutexes, etc. don't interact "correctly" with them.
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> To: wagner at elegosoft.com
> Date: Mon, 29 Dec 2008 19:16:13 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> On 29 Dec 2008, at 18:46, Olaf Wagner wrote:
>
>> Quoting Jay :
>>
>>>
>>> Note that I've been avoiding touching "mainstream" or already
>>> existant platforms -- FreeBSD, LINUXLIBC6, *_DARWIN.
>>>
>>> Perhaps I should go ahead and cross that line, as my testability/
>>> testing allows?
>>
>> I wanted to comment on this before. I've no objection at trying to
>> remove duplicated code as far as possible, but when changing system
>> interfaces (Uxxx.is), please make sure that they really work on the
>> target platform in question; if possible, add some tests.
>>
>>> Slightly linked question is if user threads should remain.
>>> They don't work, I believe on any platform, but I understand could
>>> easily be made to.
>>
>> I was not aware that user threads are broken; why?
>> Anyway, this code should not be removed; I was rather hoping for a
>> compile-time option to switch between user and system threads in cm3.
>
> Definitely doable! I've been meaning to do this for a long time now.
>
>>
>>
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin,
>> Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23
>> 45 86 95
>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:
>> Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>> DE163214194
>>
>