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

[Jay K]

The problem with the Modula-3 code is the same as usual.
It is tedious, error prone, unsafe, not portable, target-specific.
Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3.
The other -- TimePosix.m3, probably ok.

Not tremendously so in this case, just a little.

The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it.


 

The C layer is also tedious and error-prone, and maybe unsafe,
  but it is portable and target-independent, which reduces
  but tedium and error-proneness.

 


Look at the Utime.i3 cloning/extension in the Modula-3 web browsers.
They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and
the result is that the safety guaranteeds are broken.


 

C code wouldn't have this problem. It would #include <time.h> and fail to compile.

 

 

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'll have to reconfirm that I guess.
I had checked out and built the CVS tree at many dates/times, doing roughly
binary search, and narrowed it down to this.

Though Tony has undone this change.

I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well.

 

???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse).

It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.)

You know, if that succeeds, it pins the blame on ThreadWin32.m3.

If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere.

 


It /seems/ that Juno's pixmaps are getting copied over other data.

 


This change, I think, causes Juno to access violate whereas before it "only" failed assertions.

I believe it is considered fairly ok for a safe system to terminate with an assertion failure,
that might not be a bug at all, but considered far worse to hit a SIGSEGV.


formsedit crashes usually on Solaris.


Maybe other platforms. I still have to retry PPC_DARWIN. (and others?)
It seems to date to right around 1/23/2007, changing from userthreads to pthreads.
Again I checked out and built the tree at various dates, I got it to within a very
small window, like 1/20/2007 - 1/25/2007.

I haven't tried toggling pthreads on/off in head..well..I did for other reasons.
userthreads I think are broken, initialization order.

 


Can anyone confirm these problems exist?

 


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