<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>one way of being us safe and capable of doing more than traditional modification of sources each time the system changes (which is basically almost everyone blindly agrees, sorry if I'm mad, but who else aside of us cares about this?) and avoid this dangerous path to near disaster of Modula-3 specifications is to selfhost in our threads. Modula-3 has been almost hard to break system, and even if Modula-3 is modified must remain there, no UNSAFE stuff imploded, no every one in its place, no dangerous threading with locks every 10, 20 30 milliseconds, no more, we are here to say again guys just make things clear and quick and simple, don't make us to change our implementations each time you are making its.<br>I mean Linux KVM, Solaris Zones, Win HV, it isn't that hard to believe it, don't you think? Is about what guys there did with SPIN, I'm going
back to that, but is useful for one reason, the only way to keep function stability and I mean that for us in some sense could be that, remember we are able to test stress a VM in such an environment as most as we would want, knowing every fault there is ones besides HyperThreading is making its presence in hardware assisted virtualization then is a matter of what we want to achieve the next level is up to us.<br>That said originally the DEC Unix already had emulation of threads, of C POSIX threads (now called pthreads today), of Mach 3.0 layered ones and DEC OSF too and besides and own strends for more than the most of any system can think of. See:<br><span class="f"><cite>http://qstream.org/~krasic/cs508-2006/summaries/paper17/<b>Spin</b>OS.ppt<br><br></cite></span>Thanks in advance<br><br>--- El <b>jue, 21/4/11, Coleburn, Randy <i><rcolebur@SCIRES.COM></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255);
margin-left: 5px; padding-left: 5px;"><br>De: Coleburn, Randy <rcolebur@SCIRES.COM><br>Asunto: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4<br>Para: "m3devel" <m3devel@elegosoft.com><br>Fecha: jueves, 21 de abril, 2011 17:23<br><br><div id="yiv267434571"><style><!--
#yiv267434571
_filtered #yiv267434571 {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;}
_filtered #yiv267434571 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}
_filtered #yiv267434571 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}
#yiv267434571
#yiv267434571 p.yiv267434571MsoNormal, #yiv267434571 li.yiv267434571MsoNormal, #yiv267434571 div.yiv267434571MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"serif";}
#yiv267434571 a:link, #yiv267434571 span.yiv267434571MsoHyperlink
{color:blue;text-decoration:underline;}
#yiv267434571 a:visited, #yiv267434571 span.yiv267434571MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv267434571 p
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:"serif";}
#yiv267434571 span.yiv267434571EmailStyle18
{font-family:"sans-serif";color:#1F497D;}
#yiv267434571 .yiv267434571MsoChpDefault
{font-size:10.0pt;}
_filtered #yiv267434571 {margin:1.0in 1.0in 1.0in 1.0in;}
#yiv267434571 div.yiv267434571WordSection1
{}
--></style><div class="yiv267434571WordSection1"><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">Regarding CVSup, I am probably not the one to ask how important it is because I have never used it.</span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">But, I say don’t break everything else just to make CVSup work.</span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">I want the tenants of the “Green Book” to hold true for CM3 across all platforms.</span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">It would seem to me that CVSup needs to change; it is the “tail wagging the dog” at this point.</span></p><p
class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">Let’s make sure threading is fixed to work reliably again on all platforms; then go back and look at adjusting CVSup.</span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">Further, I think it safe to say that most of the folks on m3devel have bought into the philosophy and design tenants of Modula-3, as expressed in the “Green Book.” I’m not saying we shouldn’t be open to new ideas or discussion, but I for one don’t want to spend a lot of time here debating the merits of other languages. I want to spend time here trying to ensure the stability, evolution, and continued availability of
Modula-3 on as many platforms as possible. </span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">I also believe strongly that all developers should avoid resorting to coding something in C, because Modula-3 is a “systems language”. The more library stuff we can code in Modula-3 the better, as it gives us the platform independence, as expressed by Mika. It is only when using the UNSAFE subset of the language that you should ever run into a situation where an implementation has to be changed to accommodate a different platform. And, then you know exactly where to go for the changes—the UNSAFE module and use of UNSAFE features only. Everything else is completely portable.</span></p><p
class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">Regards,</span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">Randy Coleburn</span></p><p class="yiv267434571MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><div><div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;"><p class="yiv267434571MsoNormal" style="margin-left: 0.5in;"><b><span style="font-size: 10pt; font-family: "sans-serif";">From:</span></b><span style="font-size: 10pt; font-family:
"sans-serif";"> jayk123@hotmail.com [mailto:jayk123@hotmail.com] <b>On Behalf Of </b>Jay K<br><b>Sent:</b> Thursday, April 21, 2011 2:42 PM<br><b>To:</b> Coleburn, Randy; m3devel<br><b>Subject:</b> RE: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4</span></p></div></div><p class="yiv267434571MsoNormal" style="margin-left: 0.5in;"> </p><p class="yiv267434571MsoNormal" style="margin-left: 0.5in;"><span style="font-size: 10pt; font-family: "sans-serif";">> 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</span></p></div></div></blockquote></td></tr></table>