[M3devel] RC merge

[Tony Hosking]

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/20090912/814956f2/attachment-0002.html>