| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
calling pthread_exit from, or pthread_cancel on, the timer callback
thread will no longer destroy the timer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
according to posix, readv "shall be equivalent to read(), except..."
that it places the data into the buffers specified by the iov array.
however on linux, when reading from a terminal, each iov element
behaves almost like a separate read. this means that if the first iov
exactly satisfied the request (e.g. a length-one read of '\n') and the
second iov is nonzero length, the syscall will block again after
getting the blank line from the terminal until another line is read.
simply put, entering a single blank line becomes impossible.
the solution, fortunately, is simple. whenever the buffer size is
nonzero, reduce the length of the requested read by one byte and let
the last byte go through the buffer. this way, readv will already be
in the second (and last) iov, and won't re-block on the second iov.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
POSIX clearly specifies the type of msg_iovlen and msg_controllen, and
Linux ignores it and makes them both size_t instead. to work around
this we add padding (instead of just using the wrong types like glibc
does), but we also need to patch-up the struct before passing it to
the kernel in case the caller did not zero-fill it.
if i could trust the kernel to just ignore the upper 32 bits, this
would not be necessary, but i don't think it will ignore them...
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
previously NULL was returned in ai_canonname, resulting in crashes in
some callers. this behavior was incorrect. note however that the new
behavior differs from glibc, which performs reverse dns lookups. POSIX
is very clear that a reverse DNS lookup must not be performed for
numeric addresses.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
this is something of a tradeoff, as now set*id() functions, rather
than pthread_create, are what pull in the code overhead for dealing
with linux's refusal to implement proper POSIX thread-vs-process
semantics. my motivations are:
1. it's cleaner this way, especially cleaner to optimize out the
rsyscall locking overhead from pthread_create when it's not needed.
2. it's expected that only a tiny number of core system programs will
ever use set*id() functions, whereas many programs may want to use
threads, and making thread overhead tiny is an incentive for "light"
programs to try threads.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
somehow this worked on my simple fstab, but horribly broke in general,
leading to use of uninitialized offset array and crashes.
|
| |
|
|
|
| |
1. make sem_[timed]wait interruptible by signals, per POSIX
2. keep a waiter count in order to avoid unnecessary futex wake syscalls
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
since timer_create is no longer allocating a structure for the timer_t
and simply using the kernel timer id, it was impossible to specify the
timer_t as the argument to the signal handler. the solution is to pass
the null sigevent pointer on to the kernel, rather than filling it in
userspace, so that the kernel does the right thing. however, that
precludes the clever timerid-versus-threadid encoding we were doing.
instead, just assume timerids are below 1M and thread pointers are
above 1M. (in perspective: timerids are sequentially allocated and
seem limited to 32k, and thread pointers are at roughly 3G.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
with these small changes, libc functions which need to call functions
which are cancellation points, but which themselves must not be
cancellation points, can use the CANCELPT_INHIBIT and CANCELPT_RESUME
macros to temporarily inhibit all cancellation.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
note that unlike the originals, these do not print the program
name/argv[0] because we have not saved it anywhere. this could be
changed in __libc_start_main if desired.
|
| |
|
|
|
|
| |
this could actually cause rare crashes in the case where a short
string is located at the end of a page and the following page is not
readable, and in fact this was seen in gcc compiling certain files.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
the bug appeared only with requests roughly 2*sizeof(size_t) to
4*sizeof(size_t) bytes smaller than a multiple of the page size, and
only for requests large enough to be serviced by mmap instead of the
normal heap. it was only ever observed on 64-bit machines but
presumably could also affect 32-bit (albeit with a smaller window of
opportunity).
|
| |
|
|
|
|
|
| |
since vfprintf will provide a temporary buffer in the case where the
target FILE has a zero buffer size, don't bother setting up a real
buffer for vdprintf. this also allows us to skip the call to fflush
since we know everything will be written out before vfprintf returns.
|
| |
|
|
|
|
|
|
|
| |
this change makes it so most calls to fprintf(stderr, ...) will result
in a single writev syscall, as opposed to roughly 2*N syscalls (and
possibly more) where N is the number of format specifiers. in
principle we could use a much larger buffer, but it's best not to
increase the stack requirements too much. most messages are under 80
chars.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
0e10000000000000000000000000000000 was setting ERANGE
exponent char e/p was considered part of the match even if not
followed by a valid decimal value
"1e +10" was parsed as "1e+10"
hex digits were misinterpreted as 0..5 instead of 10..15
|
| |
|
|
|
|
| |
search for bytes with high bit set was giving (potentially dangerous)
wrong results. i've tested, cleaned up, and hopefully sped up this
function now.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
otherwise a signal handler could see an inconsistent and nonconformant
program state where different threads have different uids/gids.
|
