[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

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