[M3devel] RC merge

[Tony Hosking]

I'm happy with what you have done (small safe ThreadF, internal unsafe  
ThreadInternal).

Thanks.

On 13 Sep 2009, at 14:02, Jay K wrote:

>  > The Id type and MyId function is simply a convenience
>
> But what do we do about it?
> It is out there and being used.
> It ought not have been, but it was and is.
>
> The safety hole SetCurrentHandlers(WhateverState()) was also out  
> there as I understand.
>
> Should break the existing users?
> And/or move MyId to Thread.i3?
> Or ThreadFSafe.i3?
>
> I really don't think the way it was is the best choice.
> At the very least, ThreadF should either be interface instead of  
> Interface and/or UNSAFE.
> But those options have the collateral damage of breaking users of  
> ThreadF.MyId.
> I chose a route that doesn't have that damage and contains any churn  
> to within m3core.
>
>  - Jay
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Sun, 13 Sep 2009 13:43:48 -0400
> CC: mika at async.async.caltech.edu; m3devel at elegosoft.com
> Subject: Re: [M3devel] RC merge
>
> Safe code can't do anything with a value of type ADDRESS except pass  
> it around.  It must use unsafe operations (NARROW) to turn it into  
> something usable.
>
> I think you misunderstood ThreadF in the first place.  It has always  
> been logically unsafe, if not UNSAFE.  I don't want ThreadF ever to  
> come to be something that people outside the runtime system rely  
> on.  The Id type and MyId function is simply a convenience, but not  
> and never has been part of the standard interfaces.
>
> Can we please just revert back to the way it has always been?
>
> On 13 Sep 2009, at 09:51, Jay K wrote:
>
> The functions are meant to be unsafe either way.
> ThreadF.i3 clearly had a safety hole before, but not due to the  
> functions "in question".
>
> Good point about passing in ADDRESSes..but I'm not entirely sure I  
> understand/agree.
> Can safe code ("directly") generate any ADDRESSes at all? Or only  
> get them from
> unsafe code in the first place?
> ADDRESS only comes from ADR, right? And ADR isn't allowed in safe?  
> I'll check.
>
> IF safe code CAN generate ADDRESSes, then this was a hole:
> PROCEDURE SetCurrentHandlers(h: ADDRESS);
>
> and perhaps these:
> PROCEDURE SuspendOthers ();
> (* Suspend all threads except the caller's *)
>
> PROCEDURE ResumeOthers ();
>
> Though probably not the second, since safe code can trivially hang/ 
> deadlock on its own.
>
> The public safe ThreadF.i3 now just:
>
> (*-------------------------------------------------- showthreads  
> support ---*)
>
> TYPE
>   State = {
>         alive    (* can run *),
>         waiting  (* waiting for a condition via Wait *),
>         locking  (* waiting for a mutex to be unlocked *),
>         pausing  (* waiting until some time is arrived *),
>         blocking (* waiting for some IO *),
>         dying    (* done, but not yet joined *),
>         dead     (* done and joined *)
>     };
>
> (*--------------------------------------------------------------  
> identity ---*)
>
> TYPE
>   Id = INTEGER;
>
> PROCEDURE MyId(): Id RAISES {};
> (* return Id of caller *)
>
>
> Everything else I moved to the non-public ThreadInternal.i3.
>
>
> > But in Modula-3 whether an interface is unsafe or not *is* a  
> boolean.
>
> Understood, but I still think even in unsafe code, LOOPHOLE should  
> be minimized.
> C and C++ programmers are often taught to minimize casts, esp.  
> reinterpret_cast.
> I think that guidance carries over to Modula's LOOPHOLE, even if you  
> are already unsafe
> for other reasons.
>
>  - Jay
>
>
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] RC merge
> > Date: Sun, 13 Sep 2009 02:44:50 -0700
> > From: mika at async.async.caltech.edu
> >
> > Jay K writes:
> > ...
> > >
> > >Imagine you are a somewhat prolific fairly happy C or C++  
> programmer. The w=
> > >hole world is unsafe=2C but recieves a fair amount of static  
> checking and i=
> > >s therefore largely correct and perhaps doesn't even suffer much  
> from the l=
> > >ack of safety.
> > >
> > >=20
> > >
> > > void* GetFoo(void)=3B=20
> > >
> > > void* GetBar(void)=3B=20
> > >
> > >=20
> > >
> > >or
> > >
> > >=20
> > >
> > > Foo_t* GetFoo(void)=3B=20
> > >
> > > Bar_t* GetBar(void)=3B=20
> > >
> > >=20
> > >
> > >?
> > >
> > >=20
> > >
> > >Definitely the second.
> > >
> > >=20
> > >
> > >Perhaps perhaps perhaps perhaps a function should be able to be  
> declared to=
> > > return an UNTRACED REF Foo.Something=2C without actually  
> importing Foo or =
> > >defining Something?
> > >
> > >=20
> > >
> > >Clearly the safety of an /interface/ is more subtle than a boolean.
> > >
> > >Some functions may be safe and others unsafe.
> > >
> > >Even some uses of functions.
> > >
> > >Imagine for example:
> > >
> > >=20
> > >
> > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B
> > >
> > >=20
> > >
> > >Perhas a safe function could call this function=2C as long as it  
> only compa=
> > >res the return value to NIL?
> > >
> > >Actually storing it in a variable would require IMPORT Foo=2C and  
> if FOO is=
> > > declared UNSAFE=2C then that would
> > >
> > >pollute the caller. Or maybe merely declaring a variable of  
> UNTRACED is eno=
> > >ugh to wreck safety?
> >
> > But in Modula-3 whether an interface is unsafe or not *is* a  
> boolean.
> > It's very clearly defined what it means in the Green Book.
> >
> > If you don't declare your GetFoo as UNSAFE you can write
> >
> > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END
> >
> > in safe code.
> >
> > Declaring GetFoo to return ADDRESS won't let you do that. Hence,
> > it's safer, if there's a safety problem with manipulating the  
> fields.
> >
> > An interface can hardly assume that it is the only one injecting  
> objects
> > of type ADDRESS into the "safe world" so if you're allowing the  
> safe world
> > to pass these objects back in your interface you have to sanity- 
> check
> > them anyhow. You do not, however, need to worry about the fields  
> having
> > been changed by the safe code.
> >
> > If you need some more subtle properties than that you probably ought
> > to be writing UNSAFE code in the first place. Or is there some  
> trickery
> > you can do along the lines of what we came up with for small  
> integers
> > in pointers?
> >
> > Mika
>
>

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