[M3devel] RC merge
Tony Hosking
hosking at cs.purdue.edu
Sun Sep 13 19:39:39 CEST 2009
ThreadF has always been a non-standard, internal, "unpublished", non-
standard interface. At one point it wasn't even shipped (interface
not Interface). Anyway, my argument was that as such we could freely
leave it as it was. I would argue that ordinary programmers should
never even use it (it contains some very nasty low-level code like the
GC suspend routines).
On 13 Sep 2009, at 01:53, Jay K wrote:
> 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/8f1723b8/attachment-0002.html>
More information about the M3devel
mailing list