summaryrefslogtreecommitdiff
path: root/src/stdio/__stdio_read.c
AgeCommit message (Collapse)AuthorLines
2014-03-24always initialize thread pointer at program startRich Felker-7/+3
this is the first step in an overhaul aimed at greatly simplifying and optimizing everything dealing with thread-local state. previously, the thread pointer was initialized lazily on first access, or at program startup if stack protector was in use, or at certain random places where inconsistent state could be reached if it were not initialized early. while believed to be fully correct, the logic was fragile and non-obvious. in the first phase of the thread pointer overhaul, support is retained (and in some cases improved) for systems/situation where loading the thread pointer fails, e.g. old kernels. some notes on specific changes: - the confusing use of libc.main_thread as an indicator that the thread pointer is initialized is eliminated in favor of an explicit has_thread_pointer predicate. - sigaction no longer needs to ensure that the thread pointer is initialized before installing a signal handler (this was needed to prevent a situation where the signal handler caused the thread pointer to be initialized and the subsequent sigreturn cleared it again) but it still needs to ensure that implementation-internal thread-related signals are not blocked. - pthread tsd initialization for the main thread is deferred in a new manner to minimize bloat in the static-linked __init_tp code. - pthread_setcancelstate no longer needs special handling for the situation before the thread pointer is initialized. it simply fails on systems that cannot support a thread pointer, which are non-conforming anyway. - pthread_cleanup_push/pop now check for missing thread pointer and nop themselves out in this case, so stdio no longer needs to avoid the cancellable path when the thread pointer is not available. a number of cases remain where certain interfaces may crash if the system does not support a thread pointer. at this point, these should be limited to pthread interfaces, and the number of such cases should be fewer than before.
2012-11-08clean up stdio_impl.hRich Felker-0/+1
this header evolved to facilitate the extremely lazy practice of omitting explicit includes of the necessary headers in individual stdio source files; not only was this sloppy, but it also increased build time. now, stdio_impl.h is only including the headers it needs for its own use; any further headers needed by source files are included directly where needed.
2012-05-25avoid using pthread cleanup push/pop in stdio when not neededRich Felker-3/+7
unfortunately in dynamic-linked programs, these macros cause pthread_self to be initialized, which costs a couple syscalls, and (much worse) would necessarily fail, crash, and burn on ancient (2.4 and earlier) kernels where setting up a thread pointer does not work. i'd like to do this in a more generic way that avoids all use of cleanup push/pop before pthread_self has been successfully called and avoids ugly if/else constructs like the one in this commit, but for now, this will suffice.
2012-02-02make stdio open, read, and write operations cancellation pointsRich Felker-1/+10
it should be noted that only the actual underlying buffer flush and fill operations are cancellable, not reads from or writes to the buffer. this behavior is compatible with POSIX, which makes all cancellation points in stdio optional, and it achieves the goal of allowing cancellation of a thread that's "stuck" on IO (due to a non-responsive socket/pipe peer, slow/stuck hardware, etc.) without imposing any measurable performance cost.
2011-04-09work around a nasty bug in linux readv syscallRich Felker-3/+4
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.
2011-03-28major stdio overhaul, using readv/writev, plus other changesRich Felker-1/+17
the biggest change in this commit is that stdio now uses readv to fill the caller's buffer and the FILE buffer with a single syscall, and likewise writev to flush the FILE buffer and write out the caller's buffer in a single syscall. making this change required fundamental architectural changes to stdio, so i also made a number of other improvements in the process: - the implementation no longer assumes that further io will fail following errors, and no longer blocks io when the error flag is set (though the latter could easily be changed back if desired) - unbuffered mode is no longer implemented as a one-byte buffer. as a consequence, scanf unreading has to use ungetc, to the unget buffer has been enlarged to hold at least 2 wide characters. - the FILE structure has been rearranged to maintain the locations of the fields that might be used in glibc getc/putc type macros, while shrinking the structure to save some space. - error cases for fflush, fseek, etc. should be more correct. - library-internal macros are used for getc_unlocked and putc_unlocked now, eliminating some ugly code duplication. __uflow and __overflow are no longer used anywhere but these macros. switch to read or write mode is also separated so the code can be better shared, e.g. with ungetc. - lots of other small things.
2011-03-20global cleanup to use the new syscall interfaceRich Felker-1/+1
2011-02-12initial check-in, version 0.5.0v0.5.0Rich Felker-0/+6