[9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[Jens Staal]

Dear all,

From yesterday upstream mksh (cvs and future R48 and onwards) builds out
of the box on Plan9 simply by:

ape/psh
./Build.sh

One issue remains and that is that the shell will get "stuck" after
executing an external command. To build a working shell, there is a
temporary work-around by issuing:

CFLAGS="-DMKSH_NOPROSPECTOFWORK" ./Build.sh

This disables a number of features in the shell.

I have uploaded an R47 build with the modified Build.sh (with
-DMKSH_NOPROSPECTOFWORK)
at /n/sources/contrib/staal1978/pkg/mksh-R47.tbz.

In order to get a fully-functional mksh, something needs to be fixed
host-side. A good guess is that it is the way APE handles SIGCHLD,
since the same "freezing" has occurred on a number of other ports of
mksh:

http://www.mail-archive.com/miros-mksh@mirbsd.org/msg00215.html

Is there interest in fixing SIGCHLD on APE and if so, what would be the
best approach?

If there is interest, it would thus be entirely possible to have an
upstream, modern and mantained ksh shell which builds unmodified for APE
(possibly as replacement of the old pdksh port now acting as "sh").
The mksh shell is used in many different contexts, most notably as
shell in the more modern versions of Android.

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[cinap_lenrek]

plan9 kernel doesnt send notes on process exit to the parent. i do
not see any trivial way to emulate SIGCHLD as ape might spawn also
native processes so we cannot just add code to ape to emit the signal
on exit.

we might handle wait records in a separate process tho using the devproc's
wait file (that means also we would need to reimplement the various
wait functions in ape as one would get a Einuse error on wait() when
someone reads your wait file, ugh) and also generate a signal.

but its not trivial :(

--
cinap

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[erik quanstrom]

On Fri Jul 26 12:30:20 EDT 2013, cinap_lenrek@gmx.de wrote:
> plan9 kernel doesnt send notes on process exit to the parent. i do
> not see any trivial way to emulate SIGCHLD as ape might spawn also
> native processes so we cannot just add code to ape to emit the signal
> on exit.
>
> we might handle wait records in a separate process tho using the devproc's
> wait file (that means also we would need to reimplement the various
> wait functions in ape as one would get a Einuse error on wait() when
> someone reads your wait file, ugh) and also generate a signal.

we may also have to do this if we wish to support pthreads with processes.
pthreads allow one thread to wait for the children started by a second thread.

- erik

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[Jens Staal]

On Fri, 26 Jul 2013 13:01:16 -0400
erik quanstrom <quanstro@quanstro.net> wrote:

> On Fri Jul 26 12:30:20 EDT 2013, cinap_lenrek@gmx.de wrote:
> > plan9 kernel doesnt send notes on process exit to the parent. i do
> > not see any trivial way to emulate SIGCHLD as ape might spawn also
> > native processes so we cannot just add code to ape to emit the
> > signal on exit.
> >
> > we might handle wait records in a separate process tho using the
> > devproc's wait file (that means also we would need to reimplement
> > the various wait functions in ape as one would get a Einuse error
> > on wait() when someone reads your wait file, ugh) and also generate
> > a signal.


Would it be interesting to know how the other mksh ports (I think
Syllable and Win32) implemented SIGCHLD emulation? I also saw after
some googling that some tests in Go had to be ignored due to SIGCHLD
issues on Plan9, so I guess there are more use-cases than this one.
Unfortunately I know too little to actually give input on the actual
solution - most of it will come out as hot air (which hopefully won't
stink...).

>
> we may also have to do this if we wish to support pthreads with
> processes. pthreads allow one thread to wait for the children started
> by a second thread.
>
> - erik
>

A native APE pthread implementation would be awesome! I have been using
Gnu Pth some, but getting a proper APE variant would be much more
preferrable :)

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[erik quanstrom]

> Would it be interesting to know how the other mksh ports (I think
> Syllable and Win32) implemented SIGCHLD emulation? I also saw after
> some googling that some tests in Go had to be ignored due to SIGCHLD
> issues on Plan9, so I guess there are more use-cases than this one.
> Unfortunately I know too little to actually give input on the actual
> solution - most of it will come out as hot air (which hopefully won't
> stink...).

go does not use ape.

- erik

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[Aram Hăvărneanu]

> go does not use ape.

That is irrelevant to what he said.

-- 
Aram Hăvărneanu

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[erik quanstrom]

On Sat Jul 27 11:12:59 EDT 2013, aram.h@mgk.ro wrote:
> > go does not use ape.
>
> That is irrelevant to what he said.

the question at hand was the emulation of SIGCLD,
which on plan 9 is an ape-specific question.

go can't have it both ways.  either it needs to have a
solution that doesn't rely on SIGCLD, or it needs to
be ported to ape, where SIGCLD makes sense and the
ape runtime can be extendedto support it.

- erik

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[Kurt H Maier]

On Sat, Jul 27, 2013 at 11:23:03AM -0400, erik quanstrom wrote:
> On Sat Jul 27 11:12:59 EDT 2013, aram.h@mgk.ro wrote:
> > > go does not use ape.
> >
> > That is irrelevant to what he said.
>
> the question at hand was the emulation of SIGCLD,
> which on plan 9 is an ape-specific question.
>

it's an ape-specific question because the go maintainers chose to route
around the problem.  his point was that mksh is not the only program
that has run into SIGCHLD.  his point had nothing to do with whether go
uses ape, which is a question nobody has ever asked.

khm

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[erik quanstrom]

> it's an ape-specific question because the go maintainers chose to route
> around the problem.  his point was that mksh is not the only program
> that has run into SIGCHLD.  his point had nothing to do with whether go
> uses ape, which is a question nobody has ever asked.

SIGCHLD is not defined for plan 9, except in ape.  that's what i
would call ape-specific.

- erik

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[Aram Hăvărneanu]

> SIGCHLD is not defined for plan 9, except in ape.  that's what i
> would call ape-specific.

You're intentionally missing the point.

-- 
Aram Hăvărneanu

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[erik quanstrom]

On Sat Jul 27 18:41:08 EDT 2013, aram.h@mgk.ro wrote:
> > SIGCHLD is not defined for plan 9, except in ape.  that's what i
> > would call ape-specific.
>
> You're intentionally missing the point.

i don't think so.  ape must solve the sigchld problem since that
is a posix interface, and ape's raison d'etre is posix emulation.
go, not using ape and not implemeting posix, does not.  also since we
only have to worry about go, we can take a look at its specific use
of sigchld and figure out another implementation.  if the runtime is
using it, then it would be easy enough to just generate a note on exit.

- erik

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[lucio]

> SIGCHLD is not defined for plan 9, except in ape.  that's what i
> would call ape-specific.

This is degenerating into politics (or religion, same thing) quite
unnecessarily.

In my opinion, Go is a "better" APE (I'm convinced that Rob agrees
with me :-).  The way I see it and the reason I like Go a lot, is that
it seems to aim to great portability across different platforms.  In
my particular dream I saw myself developing in the comfort of Plan 9
for the Windows environment (when that still mattered) and today for
the mobile phone and various tablets (somebody keeps moving the goal
posts, but we'll catch them eventually).

In this respect, Go is perhaps closer to Posix than to APE, and then
maybe not: these are intentionally closely coupled.  Where
SIGCLD/SIGCHLD (evidently Posix didn't quite get this one nailed down)
is concerned, APE and Go need to provide the same service and
therefore need to duplicate the implementation.  If, as cinap
suggests, there is no support in the kernel for it and it cannot be
implemented purely in user user space, then it makes sense to do the
job once, in the kernel and I'd like to leave it to those who are
familiar with such things to determine what is actually necessary.

But I think it is clear that Go and APE can retain their separation,
migrating Go to APE makes no sense at all.

++L

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[Jens Staal]

On Fri, 26 Jul 2013 08:59:30 +0200
Jens Staal <staal1978@gmail.com> wrote:

> Dear all,
>
> From yesterday upstream mksh (cvs and future R48 and onwards) builds
> out of the box on Plan9 simply by:
>
> ape/psh
> ./Build.sh
>
> One issue remains and that is that the shell will get "stuck" after
> executing an external command. To build a working shell, there is a
> temporary work-around by issuing:
>
> CFLAGS="-DMKSH_NOPROSPECTOFWORK" ./Build.sh
>
> This disables a number of features in the shell.
>
> I have uploaded an R47 build with the modified Build.sh (with
> -DMKSH_NOPROSPECTOFWORK)
> at /n/sources/contrib/staal1978/pkg/mksh-R47.tbz.
>
> In order to get a fully-functional mksh, something needs to be fixed
> host-side. A good guess is that it is the way APE handles SIGCHLD,
> since the same "freezing" has occurred on a number of other ports of
> mksh:
>
> http://www.mail-archive.com/miros-mksh@mirbsd.org/msg00215.html
>
> Is there interest in fixing SIGCHLD on APE and if so, what would be
> the best approach?
>
> If there is interest, it would thus be entirely possible to have an
> upstream, modern and mantained ksh shell which builds unmodified for
> APE (possibly as replacement of the old pdksh port now acting as
> "sh"). The mksh shell is used in many different contexts, most
> notably as shell in the more modern versions of Android.

The R48 of mksh is now released, so from now on one should basically be
able to download the latest tarball at any given time from
https://www.mirbsd.org/MirOS/dist/mir/mksh/
and build it on Plan9 by

ape/psh
./Build.sh

and until the SIGCHLD thing gets resolved, just build with
CFLAGS="-DMKSH_NOPROSPECTOFWORK" ./Build.sh