<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Tony did you mean to alter Init1/Init2 in RTCollector like this?<br>Reversing the order, perhaps breaking paranoidgc, perhaps breaking user threads?<br> user threads are broken, but I had tried them in month. I was just trying them to see if they worked better..<br>Maybe you were out of date and mismerged?<br>The removal of the thread parameter to LockHeap..you had added that not too long ago, but removing it deliberate?<br><br>I don't think the Juno hang is GUI related.<br>The problematic threads I think are just dealing with the non-GUI libm3/formater thing.<br>Not certain though.<br><br> - Jay<br><br>> Date: Tue, 8 Sep 2009 07:54:58 +0000<br>> To: m3commit@elegosoft.com<br>> From: hosking@elego.de<br>> Subject: [M3commit] CVS Update: cm3<br>> <br>> CVSROOT:    /usr/cvs<br>> Changes by:      hosking@birch.  09/09/08 07:54:58<br>> <br>> Modified files:<br>>    cm3/m3-libs/m3core/src/convert/: CConvert.m3 <br>>     cm3/m3-libs/m3core/src/runtime/common/: RTAllocator.m3 <br>>                                           RTCollector.m3 <br>>                                           RTCollectorSRC.i3 <br>>                                                RTHeapInfo.m3 <br>>                                            RTHeapRep.i3 <br>>                                             RTHeapRep.m3 <br>>                                             RTHeapStats.m3 <br>>                                           RTLinker.m3 RTOS.i3 <br>>      cm3/m3-libs/m3core/src/runtime/ex_frame/: RTExFrame.m3 <br>>   cm3/m3-libs/m3core/src/runtime/ex_stack/: RTExStack.m3 <br>>   cm3/m3-libs/m3core/src/thread/POSIX/: ThreadF.i3 ThreadPosix.m3 <br>>  cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadF.i3 <br>>                                               ThreadPThread.m3 <br>>         cm3/m3-libs/m3core/src/thread/WIN32/: ThreadF.i3 ThreadWin32.m3 <br>> <br>> Log message:<br>>        Tidy up use of thread.inCritical to only occur in allocation sequences and in<br>>     thread stoppage.  This simplifies reasoning.  Refactored use of heap lock<br>>         in the process.  This may be better implemented on PTHREAD targets using a<br>>        recursive pthread mutex instead of one we roll ourselves from a non-recursive<br>>     mutex.<br>>    <br>>  Still witnessing random hangs in Juno and mentor on I386_DARWIN.<br>>  Strange, I thought this was working previously.<br>>   I wonder if there is some sort of race in the GUI code somewhere?<br>> <br></body>
</html>