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

[Coleburn, Randy]

I concur with Mika !
We need to stick to the design tennants of Modula-3.
Regards,
Randy Coleburn

-----Original Message-----
From: Mika Nystrom [mailto:mika at async.caltech.edu] 
Sent: Wednesday, April 20, 2011 10:03 PM
To: Jay K
Cc: m3devel at elegosoft.com
Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4

Jay K writes:
>--_413fd7ab-4318-4696-9889-2407f5881625_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>> > soon afterwards in the child process=2C thus resetting all states. In t=
>he
>> > meantime=2C only a short list of async-signal-safe library routines are
>> > promised to be available."
>
>
>Any idea why? I don't know.
>
>
>Is this such a burden?
>We need a global lock order for it. Unreasonable?

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?

>I understand pthread_atfork is causing a problem with user threads=2C but
>  - It really ought not. The libc vs. libpthread design is broken. I believ=
>e many systems
>    don't have this broken design=2C but I guess some do. The broken design=
> is that
>    libc and libpthread implement some functions with the same name=2C and =
>you get
>    to chose which one. And some of them might be thread-safe.
>
>
> >  In Modula-3=2C every application has *always*
> > had to assume that there are other threads floating around.  There is
>
>
>This is the case in C too.
>I can't assume any library I link to doesn't create some helper threads wit=
>h pthreads.
>pthreads should be assumed always in use=2C and there should be no ramifica=
>tions of this.
>I shouldn't have a choice e.g. of a malloc/free/strtok that aren't thread s=
>afe vs. ones that are.

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.

My comments about not supporting fork-and-do-more-work are based on the
simple observation that the normal Modula-3 libraries provide a particular
set of operations for thread control and for process creation, none of
which allow fork-and-do-more-work.  Which is why I say it is probably
legitimate to assume that people who want to fork-and-do-more-work are
on their own.

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
starts blurring the line between what is and is not Modula-3.  This could
turn out to be a problem if Modula-3 is in future again ported to systems
without complete, modern C environments.  By "problem" I mean an extra
bifurcation of application programs: some programs for "POSIX Modula-3"
and some for "other 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
smarter way than Java's sledgehammer approach of making everything pass
through a virtual machine.  In fact I remember 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.

     Mika