| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
the FPU state on receiving and returning from a signal.
The FPU save and restore macros are no longer needed, but
remain defined in case we need to use them again (something
else breaks). They'll be removed permanently once new
syscalls are added to handle the new i386 ucontext size.
|
| |
|
|
|
|
|
|
| |
`sigprocmask', `sigaltstack', and `sigwait' as well as to the
prototypes of the apparantly unimplemented functions `sigtimedwait'
and `sigwaitinfo'. This complies with IEEE Std 1003.1-2001.
|
|
|
|
| |
set.
|
|
|
|
|
|
| |
to/from a ucontext when a thread is interrupted by a signal.
This will be removed when a proper fix is made in the kernel
to save/restore the FP state without breaking the ABI.
|
| |
|
|
|
|
|
| |
Submitted by: Dan Eischen (deischen@freebsd.org)
Pointy hat for breakage just before going offline: Mini@freebsd.org
|
|
|
|
|
|
|
|
|
|
|
| |
at file flags and replace it with functions that will avoid null
pointer checks.
MFC to be done by archie ;-)
PR: 42100
Reviewed by: archie, robert
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
| |
file descriptor bit if poll() returns POLLERR, POLLHUP, or POLLNVAL.
Othewise, it's possible for select() to return successfully but
with no bits set.
Reviewed by: deischen
MFC after: 3 days
PR: bin/42175
|
|
|
|
|
|
|
|
| |
on behalf of a thread, we should check the POLLERR, POLLHUP, and
POLLNVAL flags as well to wake up the thread in these cases.
Suggested by: deischen
MFC after: 3 days
|
| |
|
|
|
|
|
|
|
|
|
|
| |
completeness and doesn't get us a working libc_r there because libc_r
uses setjmp() and setjmp() cannot be used for context switches on ia64
as-is (or sparc64). Rather than making setjmp/longjmp behave like
the *context() calls, it would be far better to make libc_r use *context()
directly which is what they are for.
Obtained from: marcel
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
initially suspended. This was preventing such threads from getting
resumed.
Reported by: Bill Huey <billh@gnuppy.monkey.org>
|
|
|
|
| |
Pointed out by: julian
|
|
|
|
|
|
| |
the process as well as pending on the current thread.
Reported by: Andrew MacIntyre <andymac@bullseye.apana.org.au>
|
|
|
|
| |
Prompted by: wollman
|
|
|
|
|
|
|
|
|
| |
file descriptors in programs linked with libc_r with flags
other than the default ones. This kept, inter alia, freopen()
from working correctly when reopening standard streams.
reviewed by: deischen
PR: misc/39377
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and pthread_resume_all_np(). These suspend and resume all threads except
the current thread, respectively. The existing functions pthread_single_np()
and pthread_multi_np(), which formerly had no effect, now exhibit the same
behaviour and pthread_suspend_all_np() and pthread_resume_all_np(). These
functions have been added mostly for the native java port.
Don't allow the uthread kernel pipe to use the same descriptors as
stdio. Mostily submitted by Oswald Buddenhagen <ossi@kde.org>.
Correct some minor style nits.
|
|
|
|
|
|
|
|
| |
pthread_page_size.
Fix a bunch line wrapping.
Pointed out by: deischen
|
|
|
|
|
|
|
| |
allow running on other arches when the instructions are supported but
the page size granularity is not.
Glanced at by: peter
|
|
|
|
|
|
|
| |
startup code rather than a static C++ object since c++ seems to be broken.
This doesn't seem to work for staticically linked program just yet, I'll
give that some more work when I get a chance.
|
|
|
|
|
|
|
|
| |
poll(2), readv(2), select(2), wait4(2), writev(2).
PR: bin/37658
Reviewed by: deischen
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
thread is already exiting.
PR: bin/37614
Reviewed by: deischen
MFC after: 1 week
|
|
|
|
|
| |
Also change one case of blatant __progname abuse (several more remain)
This commit does not touch anything in src/{contrib,crypto,gnu}/.
|
|
|
|
|
|
| |
Use __weak_reference in place of the #pragma.
Submitted by: eischen
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Change case of POLLNVAL as an error.
Remove POLLHUP and POLLERR from one case, their place is most likely
amongst read events.
PR: 33723
Submitted by: Alexander Litvin <archer@whichever.org>
Reviewed by: deischen [Provided a small change to the PR patch as well]
MFC after: 4 weeks
|
|
|
|
|
|
| |
Also, make an internal _getprogname() that is used only inside
libc. For libc, getprogname(3) is a weak symbol in case a
function of the same name is defined in userland.
|
|
|
|
|
| |
when old keys are referenced (after pthread_key_delete()) via
pthread_getspecific().
|
|
|
|
|
|
| |
these should return EBUSY when the calling thread would block.
MFC after: 2 weeks
|
|
|
|
| |
canceled or the joinee is detached.
|
|
|
|
|
|
|
| |
leave the descriptor locked, causing other threads to hang
if they happened to access the socket.
MFC after: 5 days
|
| |
|
|
|
|
|
|
|
| |
PR: misc/28947
Reviewed by: jasone, ru
Approved by: jasone, ru
MFC after: 1 week
|
|
|
|
|
|
|
|
|
| |
due to.
PR: misc/30699
Reviewed by: jasone, ru
Approved by: jasone, ru
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of an alternate signal stack for handling signals. Let the kernel
send signals on the stack of the current thread and teach the threads
signal handler how to deliver signals to the current thread if it
needs to. Also, always store a threads context as a jmp_buf. Eventually
this will change to be a ucontext_t or mcontext_t.
Other small nits. Use struct pthread * instead of pthread_t in internal
library routines. The threads code wants struct pthread *, and pthread_t
doesn't necessarily have to be the same.
Reviewed by: jasone
|
|
|
|
|
| |
set in the case of a short write, and I think returning 0 for this
is what was intended.
|
|
|
|
|
|
|
| |
size added to it in order for it to work properly when nbytes != 0.
Reviewed by: alfred
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
return address when modifying a jmp_buf to create a new thread context.
Also set t12 with the return address.
This should fix libc_r on alpha.
With much detective work by: Bernd Walter <ticso@cicely.de>
|
|
|
|
|
|
| |
archs. This should fix libc_r on alpha.
Submitted by: Bernd Walter <ticso@cicely9.cicely.de>
|
|
|
|
|
|
|
|
| |
the target thread of the join operation. This allows the cancelled
thread to detach the target thread in its cancellation handler.
This bug was found by Butenhof's cancel_subcontract test.
Reviewed by: jasone
|
|
|
|
| |
when cancelling a thread.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o) Since we unwrap the sendfile syscall, check the return value of
writev(2) to see if it didn't complete all the data.
Previously if only a partial writev() succeeded, it would proceed
to sendfile(2) even though the headers weren't completely sent.
o) Properly adjust the "bytes to send" to take into account sendfile(2)'s
behaviour of counting the headers against the bytes to be transfered
from the file.
o) Correct the problem where EAGAIN was being returned from _sys_sendfile(2)
however the wrapper didn't update the 'sent bytes' parameter to take into
account for it. This is because sendfile can return EAGAIN even though
it has actually transfered data.
Special thanks to Justin Erenkrantz <jerenkrantz@apache.org> for bringing
this to my attention and giving an excellent way to reproduce the problem.
PR: kern/32684
MFC After: 1 week
|
|
|
|
| |
eventlist == NULL or nevents == 0).
|
|
|
|
|
|
|
| |
the joining thread is in a signal handler.
Reported by: Loren James Rittle <rittle@labs.mot.com>
MFC after: 1 week
|
|
|
|
|
| |
PR: docs/31745
Submitted by: Andrew <andrew@ugh.net.au>
|
|
|
|
|
| |
PR: 31747
Submitted by: <andrew@ugh.net.au>
|