[M3devel] RC merge

[Tony Hosking]

I propose leave ThreadF safe, and revert back to MyHeapState:ADDRESS  
in ThreadF.

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:26, Jay K wrote:

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