| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
libthread had code in `_pthreadinit` to test for LinuxThreads,
and error if it was in use. This hasn't been relevant since
Linux 2.6, and I can't imagine there are many people trying to
build (recent) plan9port on systems that old.
Unfortunately, this code violated aliasing rules, and compilers
were complaining about it. But, since it likely hasn't had much
relevance in 20ish years, we can probably just remove it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
to help ease locking contention
on Linux 2.4.
|
| |
|
|
|
|
| |
last thread exits the main proc, the remaining
program ends up in the background and the
program appears to have exited.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
