[M3devel] RC merge

[jay.krell at cornell.edu]

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/20090911/eca9b909/attachment-0002.html>