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.
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.
For pthread systems that are fussy about which stack is used,
this makes sure that threadmain runs on a system stack.
If you only use proccreate (never threadcreate), all threads run
on system stacks.
Remote whitespace at the ends of lines.
Remove blank lines from the ends of files.
Change modes on source files so that they
are not executable.
Signed-off-by: Dan Cross <cross@gajendra.net>
buffers than the standard ones. 64kB appears to be enough
for a stack in that case, but let's just go nuts and make
the stacks enormous, so that it takes a few more doublings
of X's stack needs before we run into this problem again.
The VM system should take care of not actually using most
of the memory anyway.
Russ Cox
Dan Cross
Tim Wiess