plan9port changes and bugs

[Russ Cox]

Hi all,

I pushed a sequence of changes just now to simplify plan9port.

1. Pthreads are required. We were already using pthreads on every platform but NetBSD, where the build had been broken for months. Now we use it on NetBSD too, and hopefully the build is fixed there.

2. Every thread in libthread is now its own pthread. The threads are still cooperatively scheduled within their procs as before, to avoid introducing races. That is, only one pthread within a proc group is ever executing at a time. It's a bit of a waste of pthreads, but operating systems can handle lots of pthreads now, and plan9port programs were not creating lots anyway. Putting each thread in its own pthread lets each run on its own system stack, using the default pthread stack size - the various configurable stack sizes in the libthread API are now completely ignored. Putting each thread in its own pthread means we don't have to depend on having working makecontext/swapcontext routines, which work less and less often. And putting each thread in its own pthread means that all threads are easily visible to debuggers like gdb or lldb with 'thread apply all where' or 'bt all'.

3. Libthread programs that intend to run in the background by having all threads in the main proc exit, leaving behind threads in non-main procs, must declare this intention by defining:

    int 

    threadmaybackground(void)

    {
        return 1;

    }

If they don't, then instead of backgrounding when the last thread in the main proc exits, the program will sysfatal with the message "threads in main proc exited w/o threadmaybackground". This is documented in thread(3). See 7457774 for an example.

4. The spurious parent process for most threaded programs is gone. The parent process was created just in case the program tried to background itself. Now it is only created when threadmaybackground returns non-zero (there is a default returning zero provided by libthread for programs that don't declare one like above). This mainly affects ps listings and running programs under debuggers. 

5. Assembly is gone. Requiring pthread-per-thread mode allowed deleting all the custom makecontext/swapcontext implementations, and the tas-based lock implementations were already gone. The only remaining assembly was a bit of 386-specific code for libmp and libsec, but all the other architectures were using portable C code, and the 386 can too. So that's all gone, along with the 9a program.  If you have a program with assembly to assemble with the system assembler, you can set AS= in your mkfile after <$PLAN9/src/mkhdr. Without the AS=, the mkfile will try to run 'no-9a', which should be an obvious clue.

The motivation for all this cleanup was getting threaded programs running on the new Apple M1 toolchains. Threaded programs broke in subtle ways using makecontext/swapcontext but worked fine in pthread-per-thread mode. We've debugged buggy implementations of those routines - not to mention other broken tools that assume there's no stack switching outside of pthreads - for long enough. No more. 

The simplifications should help with the next port too, whatever that is. 

All that said, there are probably new bugs introduced. Please file issues if you run into any problems. 

Thanks, and happy new year!

Best,

Russ

[pmarin]

9term stopped working on NetBSD :(

Now I get:
9term: threads in main proc exited w/o threadmaybackground

> <https://github.com/9fans/plan9port/commit/74577741c856c145811061a438d5a52ea7055f39>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "plan9port-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to plan9port-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/plan9port-dev/CADSkJJU8y4XwGiehuU04_0OpFu1P_LeT%3DsfRpbf_dmuVhU0bgQ%40mail.gmail.com.
>

[Jacob Vosmaer]

Try this?

diff --git a/src/cmd/9term/9term.c b/src/cmd/9term/9term.c
index b28f44fa..d7391cf5 100644
--- a/src/cmd/9term/9term.c
+++ b/src/cmd/9term/9term.c
@@ -47,6 +47,12 @@ usage(void)
  threadexitsall("usage");
 }
 
+int
+threadmaybackground(void)
+{
+ return 1;
+}
+
 void
 threadmain(int argc, char *argv[])
 {

Op wo 30 dec. 2020 om 15:34 schreef pmarin <paco...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/plan9port-dev/CAOe8CcZh8d09jWr7r5LqkXXFWKVRff2PnOAGZ0wUvaG7abrm1A%40mail.gmail.com.

[Nicola Girardi]

Hey pmarin, until a fix is committed, just adding threadmaybackground
as Russ said fixes 9term.

diff --git a/src/cmd/9term/9term.c b/src/cmd/9term/9term.c
index b28f44fa..d7391cf5 100644
--- a/src/cmd/9term/9term.c
+++ b/src/cmd/9term/9term.c
@@ -47,6 +47,12 @@ usage(void)
threadexitsall("usage");
}

+int
+threadmaybackground(void)
+{
+ return 1;
+}
+

> https://groups.google.com/d/msgid/plan9port-dev/CAOe8CcZh8d09jWr7r5LqkXXFWKVRff2PnOAGZ0wUvaG7abrm1A%40mail.gmail.com.
>

[Russ Cox]

Fixed 9term, thanks!

[David Leimbach]

Great news! Thanks Russ!

Sent from my iPhone

On Dec 30, 2020, at 10:14 AM, Jacob Vosmaer <con...@jacobvosmaer.nl> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/plan9port-dev/CAHG0V4fhz_WHiTNFCLZkhcxC5GOVnu4BNp5PZcSbC9cGADygEA%40mail.gmail.com.

[Nicola Girardi]

On second thought, I'm not sure adding threadmaybackground() to 9term
(and stats, for that matter, which was fixed in a similar way) is the
right fix.

Maybe it's the right behavior for 9term (if I compare it to running
"window" in plan9), but it breaks existing programs that expect it to
block. (I noticed this because I have a program that calls "9term
ed".)

It doesn't seem right for stats to fork to the background (saying this
just because I don't remember ever seeing a graphical program that
forks to the background) but I guess this is not important in
practice.

I guess I can live with the changes; I'm just sharing what I found,
maybe I'm not the only one who uses 9term that way.

> https://groups.google.com/d/msgid/plan9port-dev/0178FE15-6668-4950-83B3-BD9B7BF8BF54%40gmail.com.
>

[Nicola Girardi]

Also, am I the only one having trouble with factotum?

My current OS is Linux, my login shell is rc. Experiments:

In 9term (running rc per default), I run factotum: hangs; have to SIGKILL.
In xterm (still running rc), I run factotum: shows secstore password
prompt, but hangs; have to SIGKILL.
In 9term or xterm, I enter bash first, then factotum: it asks for
secstore password, then goes to background just fine.