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

[Tony Hosking]

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>