[M3devel] gratuitous platform differences?

[Jay]

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