In libc_r, if _FDLOCKS_ENABLED is not defined, there is no guarantee
in many of the sycall wrappers that _thread_fd_table[fd] is
initialized. This causes problems for programs that pass in file
descriptors and execve() another program; when the exec'ed program
tries to do an fcntl() or other syscall on the passed-in fd, it fails.
Add calls to initialize the FD table entry for _thread_fd_lock and
_thread_fd_lock_debug.
Submitted by: Peter S. Housel <housel@acm.org>
be malloc()ed, but they are now allocated using mmap(), just as the
default-size stacks are. A separate cache of stacks is kept for
non-default-size stacks.
Collaboration with: deischen
atomically:
1) Search _thread_list for the thread to join.
2) Search _dead_list for the thread to join.
3) Set the running thread as the joiner.
While we're at it, fix a race in the case where multiple threads try to
join on the same thread. POSIX says that the behavior of multiple joiners
is undefined, but the fix is cheap as a result of the other fix.
keep track of a joiner. POSIX only supports a single joiner, so this
simplification is acceptable.
At the same time, make sure to mark a joined thread as detached so that
its resources can be freed.
Reviewed by: deischen
PR: 24345
there is no need to wake all waiters to assure that the highest priority
thread is run. As the semaphore code is written, there was no correctness
problem, but the change improves sem_post() performance.
Pointed out by: deischen
process on fork(2).
It is the supposed behavior stated in the manpage of sigaction(2), and
Solaris, NetBSD and FreeBSD 3-STABLE correctly do so.
The previous fix against libc_r/uthread/uthread_fork.c fixed the
problem only for the programs linked with libc_r, so back it out and
fix fork(2) itself to help those not linked with libc_r as well.
PR: kern/26705
Submitted by: KUROSAWA Takahiro <fwkg7679@mb.infoweb.ne.jp>
Tested by: knu, GOTOU Yuuzou <gotoyuzo@notwork.org>,
and some other people
Not objected by: hackers
MFC in: 3 days
placed in any scheduling queue(s). The process of dispatching
signals to a thread can change its state which will attempt to add
or remove the thread from any scheduling queue to which it belongs.
This can break some assertions if the thread isn't in the queue(s)
implied by its state.
When adding dispatching a pending signal to a thread, be sure to
remove the signal from the threads set of pending signals.
PR: 27035
Tested by: brian
MFC in: 1 week
a "#pragma weak" directive linking the external symbol. This matches
the other pthread_* definitions, and ensures that users of this
function from within libc get the real version, not the stub.
Suggested by: deischen
Reviewed by: deischen, alfred
associated changes that had to happen to make this possible as well as
bugs fixed along the way.
Bring in required TLI library routines to support this.
Since we don't support TLI we've essentially copied what NetBSD
has done, adding a thin layer to emulate direct the TLI calls
into BSD socket calls.
This is mostly from Sun's tirpc release that was made in 1994,
however some fixes were backported from the 1999 release (supposedly
only made available after this porting effort was underway).
The submitter has agreed to continue on and bring us up to the
1999 release.
Several key features are introduced with this update:
Client calls are thread safe. (1999 code has server side thread
safe)
Updated, a more modern interface.
Many userland updates were done to bring the code up to par with
the recent RPC API.
There is an update to the pthreads library, a function
pthread_main_np() was added to emulate a function of Sun's threads
library.
While we're at it, bring in NetBSD's lockd, it's been far too
long of a wait.
New rpcbind(8) replaces portmap(8) (supporting communication over
an authenticated Unix-domain socket, and by default only allowing
set and unset requests over that channel). It's much more secure
than the old portmapper.
Umount(8), mountd(8), mount_nfs(8), nfsd(8) have also been upgraded
to support TI-RPC and to support IPV6.
Umount(8) is also fixed to unmount pathnames longer than 80 chars,
which are currently truncated by the Kernel statfs structure.
Submitted by: Martin Blapp <mb@imp.ch>
Manpage review: ru
Secure RPC implemented by: wpaul
