Use bio(3) to read at most one line of input per iteration, even
if there is more than one line available in the input buffer. This
makes it easier to interact with line-oriented ctl files like that of
factotum(4) from shell scripts, without the need to control when
and how much data is flushed to a pipe.
This fixes the 'run stats from rc; exit rc; stats dies' problem.
It's unclear whether this is the right fix or whether rc should
be starting all its interactive commands in their own process
groups. But at least it does fix stats dying.
Usually r->nused < r->nalloc and the read is in bounds.
But it could in theory be right on the line and reading
past the end of the allocation.
Make it safe but preserve as much of the old semantics
as possible. This use of rterm appears to be only for
optimization purposes so the result does not matter
for correctness.
For whatever reason all three of these programs
contain switches like:
switch(x) {
case 1:
if(cond)
case 2:
f();
}
Like Duff's device, this is legal C but more obscure
than it really needs to be.
This commit assumes those are intended as written
and simply writes them more clearly. I did consider
that maybe they are mistakes, but in the case of sam/regexp.c,
my rewrite in this commit matches the acme/regx.c that
has been in plan9port since I added acme in 2003.
(I didn't bother to dig up the old Plan 9 releases.)
Assuming acme/regx.c has been correct for the past
two decades, this commit should be correct too.
Now that we assume pthreads, the only assembly
left is in libmp and libsec.
We only ever added assembly for 386.
The portable C code is fine for plan9port.
Now that everything uses pthreads and pthreadperthread,
can delete various conditionals, all the custom context code,
and so on. Also update documents.
Fixes#355.
Programs that want to background themselves now need
to define threadmaybackground returning 1.
This avoids a confusing (to people and debuggers)
extra parent process for all the threaded programs
that will never want to background themselves.
I added a direct call from thread.c to pthread.c's _threadpthreadstart
in May, and no one has complained about NetBSD being broken.
So probably no one is using this on NetBSD at all.
Make pthread the only option.
Drawing as white on black to produce a mask only works if
the white on black is the inversion of black on white.
Emoji that force use of specific colors don't respect that.
Draw black on white and invert to mask separately.
This fixes https://github.com/9fans/plan9port/issues/436
This doesn't necessarily address the underlying issue: calling p9create with
mode = OREAD should probably be allowed, but currently doesn't work on
OpenBSD.
Unclear why it is here (wkj added it long ago).
It has never been installed into $PLAN9/bin,
so it's doubtful that anyone has ever used it.
Arnold Robbins has an alternate version at
https://github.com/arnoldrobbins/dformat.
Fixes#421.
List mode was constrained to the BMP. This change introduces
the following new list mode convention, using Go string literal syntax:
Non-printing ASCII characters display as \xhh.
Non-ASCII characters in the BMP display as \uhhhh.
Characters beyond the BMP display as \Uhhhhhhhh.
Runes in Plan 9 were limited to the 16-bit BMP when I drew up
the RPC protocol between graphical programs and devdraw
a long time ago. Now that they can be 32-bit, use a 32-bit wire
encoding too. A new message number to avoid problems with
other clients (like 9fans.net/go).
Add keyboard shortcut alt : , for U+1F602, face with tears of joy,
to test that it all works.
ASAN can't deal with the coroutine stacks.
In theory we can call into ASAN runtime to let it know about them,
but ASAN still has problems with fork or exit happening from a
non-system stack. Bypass all possible problems by just having
a full OS thread for each libthread thread. The threads are still
cooperatively scheduled within a proc (in thos mode, a group of OS threads).
Setting the environment variable LIBTHREAD=pthreadperthread
will enable the pthreadperthread mode, as will building with
CC9FLAGS='-fsanitize=address' in $PLAN9/config.
This solution is much more general than ASAN - for example if
you are trying to find all the thread stacks in a reproducible crash
you can use pthreadperthread mode with any debugger that
knows only about OS threads.
getdirentries(2) has been deprecated on macOS since 10.5 (ten releases ago).
Using it requires disabling 64-bit inodes, but that in turn makes binaries
incompatible with some dynamic libraries, most notably ASAN.
At some point getdirentries(2) will actually be removed.
For both these reasons, switch to opendir/readdir.
A little clunky since we have to keep the DIR* hidden away
to preserve the int fd interfaces, but it lets us remove a bunch
of OS-specific code too.
This fixes at least one shell script (printfont) that expected
'x'`{y}'z'
to mean
'x'^`{y}^'z'
as it now does. Before it meant:
'x'^`{y} 'z'
One surprise is that adjacent lists get a free carat:
(x y z)(1 2 3)
is
(x1 y2 z3)
This doesn't affect any rc script in Plan 9 or plan9port.
The old yacc-based parser is available with the -Y flag,
which will probably be removed at some point.
The new -D flag dumps a parse tree of the input,
without executing it. This allows comparing the output
of rc -D and rc -DY on different scripts to see that the
two parsers behave the same.
The rc paper ends by saying:
It is remarkable that in the four most recent editions of the UNIX
system programmer’s manual the Bourne shell grammar described in the
manual page does not admit the command who|wc. This is surely an
oversight, but it suggests something darker: nobody really knows what
the Bourne shell’s grammar is. Even examination of the source code is
little help. The parser is implemented by recursive descent, but the
routines corresponding to the syntactic categories all have a flag
argument that subtly changes their operation depending on the context.
Rc’s parser is implemented using yacc, so I can say precisely what the
grammar is.
The new recursive descent parser here has no such flags.
It is a straightforward translation of the yacc.
The new parser will make it easier to handle free carats
in more generality as well as potentially allow the use of
unquoted = as a word character.
Going through this exercise has highlighted a few
dark corners here as well. For example, I was surprised to
find that
x >f | y
>f x | y
are different commands (the latter redirects y's output).
It is similarly surprising that
a=b x | y
sets a during the execution of y.
It is also a bit counter-intuitive
x | y | z
x | if(c) y | z
are not both 3-phase pipelines.
These are certainly not things we should change, but they
are not entirely obvious from the man page description,
undercutting the quoted claim a bit.
On the other hand, who | wc is clearly accepted by the grammar
in the manual page, and the new parser still handles that test case.
It may be that pthreads on NetBSD is now good enough,
but the build as written (introduced in 23a2368 at my suggestion)
is certainly broken, since both NetBSD.c and pthread.c define
the same functions.
If NetBSD does support pthreads now, then a few things
should happen together:
- libthread/sysofiles.sh should drop its top NetBSD case entirely
- libthread/NetBSD.c should be deleted
- libthread/NetBSD-*-asm.s should be deleted
- include/u.h's NetBSD case should define PLAN9PORT_USING_PTHREADS
and #include <pthread.h>
For now, restore to less clearly broken build.
Linux.c was for Linux 2.4 and is no longer used directly,
only indirectly because NetBSD.c was a 1-line file #including Linux.c.
So mv Linux.c NetBSD.c.
Also rm Linux-*-asm.s which was for Linux 2.4 as well.
They were just a duplicate of my(get|set)mcontext from the other
assembly file, and unused from threadimpl.h.
Change-Id: Id8003e5177ed9d37a7f0210037acbe55bbf7f708
The issue manifests in fork: POSIX fork mandates that a
fork'd process is created with a single thread. If a
multithreaded program forks, and some thread was in
malloc() when the fork() happened, then in the child
the lock will be held but there will be no thread to
release it.
We assume the system malloc() must already know how to
deal with this and is thread-safe, but it won't know about
our custom spinlock. Judging that this is no longer
necessary (the lock code was added 15 years ago) we remove
it.
Signed-off-by: Dan Cross <cross@gajendra.net>
