[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4

[Jay K]

> I concur with Mika !
> We need to stick to the design tennants of Modula-3.

ok...so..is someone volunteering to fix cvsup? Or are we willing to break it?
And does this solve any larger problems?
ie: are the changes to support cvsup really what broke anything?
  ok, yes, for now, they have broken user threads.


> You mean that the application needs a global (partial) lock order
> for it?  Somehow an application that wants to use facilities to
> fork-and-do-more-work has to call pthread_atfork with the order
> established, or have I misunderstood?  That means every library
> that has locks has to register them somewhere?

Yes.
Not register the locks per se, but register callbacks.
Those callbacks need to acquire/release locks though.
Essentially what you said though.

> Well there are versions of C that don't define threads at all (especially
> historical versions of C).  A programmer using such a version might legitimately
> assume there are no threads except the main program.


Hardly.
Threads have been widespread for a long time now.
Pretending they don't exist seems kind of dumb.

> people who want to fork-and-do-more-work are
> on their own.

"on their own" meaning they have an arbitrary unbounded set of problems?
We will completely ignore them?
Will break cvsup?
Is using pthread_atfork really so difficult??


> I also think one of the valuable aspects of Modula-3 is that it defines
> a complete systems programming environment already with the facilities in
> Thread and Process, and that adding support for more facilities in m3core


Modula-3 is several things. It is a language. It is libraries. Maybe other things.
The libraries might might be split into "green book" and others.
To what extent should we support "others"?
Just the fact that m3core exposes Unix.fork() gets us into "others".
Anyway..I think there is this idea of Modula-3 being a closed system.
Limit yourself to a smaller set of libraries and practises and ok.
Go to far into the world of other libraries and things that work in C and can
work in Modula-3, and things start breaking.
It seems gray to me, what should work, what the overall approach should be.


> bifurcation of application programs: some programs for "POSIX Modula-3"
> and some for "other Modula-3".

I believe this exists. Do we not have X-Windows apps in Modula-3 and Win32 apps in Modula-3?


> It was definitely a design goal of the
> language to provide interfaces that were simple and general enough that
> application code would be "write once, run anywhere"---and to do it in a

You can make a big push in this direction, but you'll never get there.
People will always want more libraries. Some they will write brand new in Modula-3, good.
Many others will already exist in C and C++ and they will want to reuse.


> it was a point of pride with SRC M3 that no conditional compilation was needed to account for
> OS and architecture differences even though the SRC distribution had
> been ported to a rather large variety of computers.


They did worse things instead.
They had large swaths of duplicated code, per-target, that was almost the same per-target.
Sometimes the code was code, sometimes declarations. The declarations were very
tedious and error-prone to write and recieved no static checking.
They had runtime checks for what the target was -- thus the problem where libm3 was
tied to the exact list of targets available.


Conditional compilation can be a good thing.


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