[M3devel] gratuitous platform differences?

[Jay]

(There is an ASSERT in two of the styles, but it apparently got removed by some buggy mail software in the stack..)
 
 
  - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Wed, 28 Jan 2009 15:56:42 +0000
> Subject: Re: [M3devel] gratuitous platform differences?
>
>
> Another difference is that some platforms set the last page of the stack to be PROT_NONE, while others use PROT_READ, with a comment:
>
> (* The protection should be 0, but making the page read-only
> is good enough to prevent unchecked runtime errors *)
>
> except ALPHA_OSF says:
>
> (* The protection should be 0, but a bug in MIPS/Ultrix 4.2 (vmdup)
> causes kernel panics when it is. Making the page read-only
> is good enough to prevent unchecked runtime errors *)
>
> Also, whenever calling Usignal stuff, there are three styles
>
> i := Usignal.something()
>
>
>
> WITH i = Usignal.something() DO
>
> END;
>
>
> EVAL Usignal.something()
>
>
>
> It COULD be that the functions fail on some platforms and EVAL is used to ignore the result.
> I favor the first style -- I find that code should avoid indentation in general -- given a choice between an if/else and if/continue, I'll use if/continue, adding a local variable or using WITH, add a local variable. Etc.
>
>
> - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Wed, 28 Jan 2009 14:37:20 +0000
>> Subject: [M3devel] gratuitous platform differences?
>>
>>
>> I'm looking to add user thread support to the stuff I'm working on.
>> As part of this, I'm surveying various platform-specific code,
>> to find the commonality.
>> Some of this should be common Modula-3 code.
>> Where there are dealings with struct sigaction or sigset_t, the
>> code should be rewritten in C to avoid requiring other additional
>> platform-dependent code.
>>
>>
>> It seems to me that many of the differences are gratuitous.
>>
>>
>> Here are two:
>>
>>
>> - some platforms unmap, or at least take away write access, to the
>> last page in the stack; and then remap it (or add back write access)
>> before disposing
>> Now, I'm not going to move all ports to "my rewritten headers",
>> just ones that I can test and are "somewhat active".
>> In this case, I think that leads to all platforms being the same.
>> So the question of "why not always do this?" doesn't matter.
>>
>>
>> - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms
>> initialize the mask in the module's initializer, some recreate it
>> for every call.
>> Is there a reason for this?
>> Creating it once is faster.
>> But does require the initializer run early enough.
>> And one would hope that the cached struct isn't too huge and memory wasting.
>>
>>
>> To be safe, I could just provide two versions here, one that makes the mask
>> over and over, one that does not.
>>
>>
>> - Jay