[M3commit] [M3devel] CVS Update: cm3

[Jay]

Understood. You (someone) also has to fix the initialization.
I think when you (you) moved the various user thread globals (?), such as the handler chain, into one nice thread object, "switchable" via just one pointer, it broke.
 
I didn't look at the change in depth, I'm making a leap in my description of what you did.
It is a /very/ reasonable design (or even likely The Correct Design), to collect up all the globals that represent a "thread" into one heap allocated struct...except it is an "object".
 
 
I don't have SOLgnu/sun handy, this week, but can try it next week.
I expect it fails as PPC_LINUX was.
 
 
I THINK the "object" needs to be changed to a "traced ref" and then it can be initialized using, maybe, a preallocated global, for the first thread, or at least using regular "Malloc" and not going through the garbage collection...but I'm really just not sure.
If I get X86_MSDOS/DJGPP up and going, I'll be a bit more motivated..but I think I'll so I386_SOLARIS first, since it is perhaps more modern/mainstream.
 
 
You know, I tried having it NEW the object on-demand, but I think that ended up recursing to about the same place -- PushEFrame.
It's "difficult" to repro now for me, this week, based on hardware/OS availability,because I ripped out PPC_LINUX user thread support (unless I install NetBSD/FreeBSD in a VM or use birch, all of which are, honestly, easy).
 
 
 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Mon, 29 Dec 2008 11:14:02 +1100
> CC: jkrell at elego.de; m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> User threads used to work on Solaris (since it uses getcontext/
> setcontext to do thread switching instead of setjmp/longjmp) and these
> should work similarly on Linux/BSD/OSX. The only problem is that we
> need to use makecontext on some platforms to get a proper basis
> context for new threads (as opposed to using the hackier code that is
> there in ThreadPosix.m3.
>
> On 29 Dec 2008, at 10:55, Jay wrote:
>
>>
>> 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?
>>
>> 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.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu; jkrell at elego.de
>>> Date: Sun, 28 Dec 2008 23:49:25 +0000
>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>> Subject: Re: [M3commit] CVS Update: cm3
>>>
>>>
>>> This one I can undo and still feel ok -- just push sem_t into
>>> Utypes.i3 and expose it from a common Usem.i3.
>>> There is only one sem_t in the system.
>>> It is global. This change just makes it usually larger and more
>>> aligned than necessary.
>>>
>>>
>>> The danger would be if sem_t is ever embedded in something else OS-
>>> defined, or if the OS ever returned a pointer to one that Modula-3
>>> code copied.
>>>
>>>
>>> In general, I'm thinking either Utypes.i3 or some new Uinternal.i3
>>> or Usysdep.i3 or Utypes.i3 + Uconstants.i3 should be where most/all
>>> system-dependent stuff.
>>> Even existant Utypes.i3 have much redundancy -- all the ulong/
>>> ushort/int8/int16/int32/int64 types are always the same, just stuff
>>> like nlink_t, mode_t, gid_t, uid_t, off_t vary. Though imho off_t
>>> should always be INT64 or UINT64.
>>>
>>>
>>> Usysdep.i3 seems best?
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> To: jkrell at elego.de
>>>> Date: Mon, 29 Dec 2008 09:50:37 +1100
>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>
>>>> This change makes me uneasy -- do you mean to say we have a uniform
>>>> definition of sem_t when the different targets have different
>>>> definitions? :-O
>>>>
>>>> On 28 Dec 2008, at 11:03, Jay Krell wrote:
>>>>
>>>>> CVSROOT: /usr/cvs
>>>>> Changes by: jkrell at birch. 08/12/28 11:03:34
>>>>>
>>>>> Modified files:
>>>>> cm3/m3-libs/m3core/src/unix/Common/: m3makefile
>>>>> cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile
>>>>> cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile
>>>>> Added files:
>>>>> cm3/m3-libs/m3core/src/unix/Common/: Usem.i3
>>>>> Removed files:
>>>>> cm3/m3-libs/m3core/src/unix/linux-common/: Usem.i3
>>>>> cm3/m3-libs/m3core/src/unix/openbsd-common/: Usem.i3
>>>>>
>>>>> Log message:
>>>>> another common header file -- however this bought by defining sem_t
>>>>> to have the maximum size and alignment of any system;
>>>>> Solaris's 48 byte 64bit aligned version
>>>>> The CM3 code base has one static sem_t in the pthread code.
>>>>
>