[M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?

Tony Hosking hosking at cs.purdue.edu
Wed Sep 23 03:40:27 CEST 2009


On 22 Sep 2009, at 08:16, Jay K wrote:

> Yes there is fairly definitely a problem on Windows and it dates, I  
> think, to this change:
>
>
> 2009-02-16 02:20  hosking
>   * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ 
> dtoa.c,
>     Csupport/little-endian/dtoa.c, convert/CConvert.i3,
>     convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3,
>     runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3,
>     runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3,
>     thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3,
>     thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3,
>     thread/WIN32/ThreadWin32.m3:
>   Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better  
> match underlying pthread semantics.
>   This means that RTOS.WaitHeap must be called while RTOS.LockHeap  
> is held.
>   RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or  
> not.

I'm not convinced that this change itself broke things, but perhaps  
instead exposed the brokenness.  In any case, debugging this in the  
head will probably be easiest.  If we have an example that  
deterministically breaks then I think we have a place to start.  My  
suggestion for now, since it appears to trigger the problem, is to use  
@M3nogc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090922/5bc11f92/attachment-0002.html>


More information about the M3devel mailing list