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

[Tony Hosking]

On 22 Sep 2009, at 10:00, Randy Coleburn wrote:

> Jay your message seems truncated again.
>
> Threads have always worked for me in the past on Windows.  Do we  
> have some sort of tests we can run to prove correctness of  
> threading?  Seems to me that Juno is the only thing that isn't  
> working right, supposedly wrt threading.  Perhaps the problem lies  
> in Juno and not threads.  Maybe Juno is misusing threads in some way  
> or there is a bug in something Juno uses that exhibits itself as a  
> thread problem.  Granted, the last time I did heavy checks on my  
> multithreaded code on Windows was before the date you say a problem  
> was introduced, so maybe it is broken now.  In any event, I think  
> some standard regression type tests would be in order here.  If we  
> don't have them, perhaps Tony could offer some suggestions.  I would  
> be glad to write some of these tests if given some general ideas on  
> what to check for.

I'm not so convinced it is the threading code per se.  Could be that  
we just tripped over it with some random change.  The fact that we see  
problems arising with @M3nogc suggests that the clobber is outside the  
GC and threading code.  Something deeper in the Windows VBT stuff  
perhaps?

>  I don't want to get into a big argument with you (or anyone else),  
> but I do take exception with your statements about Modula-3 being  
> "tedious, error prone, unsafe, not portable, target-specific."   
> Perhaps I am misinterpreting you here and you are specifically  
> referencing a particular set of Modula-3 code that was done poorly.   
> If so, then perhaps if you could explain what is wrong with the  
> Modula-3 code in question, one of us can step up to the plate and  
> make some corrections.  If the SPIN folks could write an OS in  
> Modula-3, surely we can write the compiler and library code in  
> Modula-3.  IMO, writing such code in Modula-3 should give us the  
> benefits of Modula-3 instead of the deficiencies of C.  After all,  
> this mail list is for Modula-3 enthusiasts.  We wouldn't be spending  
> time if we didn't think this language was great.

PS Randy, in this case I think Jay is making the point that all of the  
Unix interfaces clones from C header files have no guarantees that  
they match the original C code.  Jay's changes should result in a much  
cleaner, easier to port system, since problems in the bridging code  
from M3 to C will be caught by the C compiler.

>
> Regards,
> Randy
>
> >>> Jay K <jay.krell at cornell.edu> 9/22/2009 8:16 AM >>>
>
> 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