[M3devel] RC merge

Sun Sep 13 07:53:18 CEST 2009

Imagine you are a somewhat prolific fairly happy C or C++ programmer. The whole world is unsafe, but recieves a fair amount of static checking and is therefore largely correct and perhaps doesn't even suffer much from the lack of safety.

 void* GetFoo(void); 

 void* GetBar(void); 

or

 Foo_t* GetFoo(void); 

 Bar_t* GetBar(void); 

?

Definitely the second.

Perhaps perhaps perhaps perhaps a function should be able to be declared to return an UNTRACED REF Foo.Something, without actually importing Foo or defining Something?

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:

PROCEDURE GetFoo(): UNTRACED REF Foo.Something;

Perhas a safe function could call this function, as long as it only compares the return value to NIL?

Actually storing it in a variable would require IMPORT Foo, and if FOO is declared UNSAFE, then that would

pollute the caller. Or maybe merely declaring a variable of UNTRACED is enough to wreck safety?

Either way, I do grant, that it probably isn't worth deciding or making any language changes whatsoever.

It should suffice for programmers to partition any given bunch of code conceptual interface Foo

into SAFE INTERFACE Foo and UNSAFE INTERFACE FooF or FooInternal or FooUnsafe.

I think I shall rename ThreadUnsafe to ThreadInternal amd merge the two ThreadInternals into one,

as long as the contents of each exist in all of them, even though, granted, there

aren't callers of all of them.

"Unsafe" is shorter but "Internal" seems maybe better.

ThreadF will remain safe and very small.

We could move its resulting lone function into Thread, but I think it isn't worth breaking

any callers outside m3core.

Furthermore I'll endeavor to remove ADDRESS as a return type in ThreadInternal, replacing

it with actual types, in order to remove casts, and make the unsafe code get just a little

bit more static safety/checking.

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Sat, 12 Sep 2009 07:38:43 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] RC merge

But in this case the caller is highly privileged code that is already UNSAFE, so who cares?

On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote:

I don't like the caller to have to cast.

 - Jay (phone)

On Sep 11, 2009, at 7:19 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:

Yes, that was exactly my intention.  I wasn't quite sure what your problem was with the code I had returning ADDRESS, but was willing to accede.  It is "safe", but you can't use the result unless in UNSAFE code.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484

On 11 Sep 2009, at 17:33, Jay K wrote:

ps: I think there's another funny thing here:
I think you can have:

INTERFACE FooInterface;

PROCEDURE SafeFunction();
PROCEDURE UnsafeFunction()=ADDRESS;

END FooInterface.

Despite being in a safe interface, UnsafeFunction either can't be called
from safe code, or at least its return value can't be used? Or at least
can't be done anything with but compare to NIL?
I think.
Therefore this interface could be said to be "partially unsafe".

Perhaps not a useful middle ground though.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] RC merge
Date: Fri, 11 Sep 2009 21:26:00 +0000

Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be.

I propose a few options:
 1 - asis, probably not
 2 - rename/merge ThreadUnsafe to ThreadInternal
 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too

2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal

3 maybe gratuitously breaks folks but is a clean result

 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe.

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Fri, 11 Sep 2009 16:51:11 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] RC merge

Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff.

FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system.  Is there any need for it really to be safe?

On 11 Sep 2009, at 16:05, Jay K wrote:

Tony I'll double check if I see the hang. NT386 still crashes.

http://www.modula3.com/cm3/ChangeLog-2009

"
2009-09-08 05:54 hosking

  * m3-libs/m3core/src/: convert/CConvert.m3,
    runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3,
    runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3,
    runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3,
    runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3,
    runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3,
    runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3,
    thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3,
    thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3,
    thread/WIN32/ThreadWin32.m3:

  Tidy up use of thread.inCritical to only occur in allocation sequences and in
  thread stoppage.  This simplifies reasoning.  Refactored use of heap lock
  in the process.  This may be better implemented on PTHREAD targets using a
  recursive pthread mutex instead of one we roll ourselves from a non-recursive
  mutex.

  Still witnessing random hangs in Juno and mentor on I386_DARWIN.
  Strange, I thought this was working previously.
  I wonder if there is some sort of race in the GUI code somewhere?
"

??-  Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Fri, 11 Sep 2009 12:46:19 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] RC merge

No, the hangs in Juno and mentor are no longer there.  I cannot reproduce them on I386_DARWIN.

On 11 Sep 2009, at 10:24, Jay K wrote:

But the hangs are still present, right? Worth merging without that fixed?

How does one do it easily?
I wish we used Perforce. :(

 - Jay

From: hosking at cs.purdue.edu
To: m3devel at elegosoft.com
Date: Fri, 11 Sep 2009 09:45:23 -0400
Subject: [M3devel] RC merge

Can someone merge my recent deep fixes to pthreads threading over to the release branch?  I won't get a chance to do so until next Monday at the earliest.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484

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