<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> I concur with Mika !<br>> We need to stick to the design tennants of Modula-3.<br><br>ok...so..is someone volunteering to fix cvsup? Or are we willing to break it?<br>And does this solve any larger problems?<br>ie: are the changes to support cvsup really what broke anything?<br> ok, yes, for now, they have broken user threads.<br><br><br>> You mean that the application needs a global (partial) lock order<br>> for it? Somehow an application that wants to use facilities to<br>> fork-and-do-more-work has to call pthread_atfork with the order<br>> established, or have I misunderstood? That means every library<br>> that has locks has to register them somewhere?<br><br>Yes.<br>Not register the locks per se, but register callbacks.<br>Those callbacks need to acquire/release locks though.<br>Essentially what you said though.<br><br>> Well there are versions of C that don't define threads at all (especially<br>> historical versions of C). A programmer using such a version might legitimately<br>> assume there are no threads except the main program.<br><br><br>Hardly.<br>Threads have been widespread for a long time now.<br>Pretending they don't exist seems kind of dumb.<br><br>> people who want to fork-and-do-more-work are<br>> on their own.<br><br>"on their own" meaning they have an arbitrary unbounded set of problems?<br>We will completely ignore them?<br>Will break cvsup?<br>Is using pthread_atfork really so difficult??<br><br><br>> I also think one of the valuable aspects of Modula-3 is that it defines<br>> a complete systems programming environment already with the facilities in<br>> Thread and Process, and that adding support for more facilities in m3core<br><br><br>Modula-3 is several things. It is a language. It is libraries. Maybe other things.<br>The libraries might might be split into "green book" and others.<br>To what extent should we support "others"?<br>Just the fact that m3core exposes Unix.fork() gets us into "others".<br>Anyway..I think there is this idea of Modula-3 being a closed system.<br>Limit yourself to a smaller set of libraries and practises and ok.<br>Go to far into the world of other libraries and things that work in C and can<br>work in Modula-3, and things start breaking.<br>It seems gray to me, what should work, what the overall approach should be.<br><br><br>> bifurcation of application programs: some programs for "POSIX Modula-3"<br>> and some for "other Modula-3".<br><br>I believe this exists. Do we not have X-Windows apps in Modula-3 and Win32 apps in Modula-3?<br><br><br>> It was definitely a design goal of the<br>> language to provide interfaces that were simple and general enough that<br>> application code would be "write once, run anywhere"---and to do it in a<br><br>You can make a big push in this direction, but you'll never get there.<br>People will always want more libraries. Some they will write brand new in Modula-3, good.<br>Many others will already exist in C and C++ and they will want to reuse.<br><br><br>> it was a point of pride with SRC M3 that no conditional compilation was needed to account for<br>> OS and architecture differences even though the SRC distribution had<br>> been ported to a rather large variety of computers.<br><br><br>They did worse things instead.<br>They had large swaths of duplicated code, per-target, that was almost the same per-target.<br>Sometimes the code was code, sometimes declarations. The declarations were very<br>tedious and error-prone to write and recieved no static checking.<br>They had runtime checks for what the target was -- thus the problem where libm3 was<br>tied to the exact list of targets available.<br><br><br>Conditional compilation can be a good thing.<br><br><br> - Jay<br> </body>
</html>