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.
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.
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
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.
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.
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.
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
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>
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
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
