[M3devel] awful race condition in libm3/FilePosix.m3?

[Daniel Alejandro Benavides D.]

Hi all:
you can still use simulated I/O error using a faulty memory component address to some extent, for instance a VAX9000 would immediately shutdown the memory to processor circuit, and kill process using it if possible.
If a HW error is scanned and detected prior completion of the program the value is  detected by the test scanner  and thus avoid  the instruction completion or refusing to run the program (silently or verbosely). 
Alpha had a similar feature but in execution time. Sorry i don't thing I remember that well  details.
In a different processor there might be aleatory error in CPU but it won't stop the process already running which is UNSAFE, that's where you might want to use some NIL constant, but in general you cannot "simulate" that error only with that system trap as said because you can prevent the error or ignore it  in a safe way (obviously not with other processors misleading errors).

Thanks in advance

--- El sáb, 2/2/13, Darko <darko at darko.org> escribió:

De: Darko <darko at darko.org>
Asunto: Re: [M3devel] awful race condition in libm3/FilePosix.m3?
Para: mika at async.caltech.edu
CC: m3devel at elegosoft.com
Fecha: sábado, 2 de febrero, 2013 03:19

I agree with Mika's use of style, but it isn't really affected by the proposed change. I've always thought the notion that the compiler would ever initialize a reference to a value other than Nil unconvincing. The exception would be TEXT references. Then there might be others in the future. The argument for keeping the definition as it is is that it's simple.

On Feb 1, 2013, at 10:16 PM, mika at async.caltech.edu wrote:

> "Rodney M. Bates" writes:
> ...
>> I would expect this to crash because m would be default initialized to NIL,
>> which when dereferenced, would show up as a segfault, in any M3 implementation
>> I have experience with.
>> 
>> Actually, the language only says it has to be initialized to a bit
>> pattern that represents some member of the type.  But for or any reference
>> type, the only sensible choice for a compiler to make would be NIL.
>> 
>> Perhaps we should change the language to say this explicitly?  I am
>> very confident it wouldn't undermine either any existing code or compiler,
>> and might save some grief in the future.
> ...
> 
> The only problem with this proposal is that to me, as a human,
> 
> VAR m : MUTEX := NIL;
> 
> ...
> 
> today means something different from
> 
> VAR m : MUTEX;
> 
> notwithstanding the fact that the compiler may implement them the same way.
> 
>     Mika
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130202/dfea7cc0/attachment-0002.html>