[M3commit] CVS Update: cm3

[Jay K]

Tony did you mean to alter Init1/Init2 in RTCollector like this?
Reversing the order, perhaps breaking paranoidgc, perhaps breaking user threads?
 user threads are broken, but I had tried them in month. I was just trying them to see if they worked better..
Maybe you were out of date and mismerged?
The removal of the thread parameter to LockHeap..you had added that not too long ago, but removing it deliberate?

I don't think the Juno hang is GUI related.
The problematic threads I think are just dealing with the non-GUI libm3/formater thing.
Not certain though.

 - Jay

> Date: Tue, 8 Sep 2009 07:54:58 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	hosking at birch.	09/09/08 07:54:58
> 
> Modified files:
> 	cm3/m3-libs/m3core/src/convert/: CConvert.m3 
> 	cm3/m3-libs/m3core/src/runtime/common/: RTAllocator.m3 
> 	                                        RTCollector.m3 
> 	                                        RTCollectorSRC.i3 
> 	                                        RTHeapInfo.m3 
> 	                                        RTHeapRep.i3 
> 	                                        RTHeapRep.m3 
> 	                                        RTHeapStats.m3 
> 	                                        RTLinker.m3 RTOS.i3 
> 	cm3/m3-libs/m3core/src/runtime/ex_frame/: RTExFrame.m3 
> 	cm3/m3-libs/m3core/src/runtime/ex_stack/: RTExStack.m3 
> 	cm3/m3-libs/m3core/src/thread/POSIX/: ThreadF.i3 ThreadPosix.m3 
> 	cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadF.i3 
> 	                                        ThreadPThread.m3 
> 	cm3/m3-libs/m3core/src/thread/WIN32/: ThreadF.i3 ThreadWin32.m3 
> 
> Log message:
> 	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?
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090908/4412f07c/attachment-0002.html>