| Age | Commit message (Collapse) | Author | Lines |
|---|
|
i did some testing trying to switch malloc to use the new internal
lock with priority inheritance, and my malloc contention test got
20-100 times slower. if priority inheritance futexes are this slow,
it's simply too high a price to pay for avoiding priority inversion.
maybe we can consider them somewhere down the road once the kernel
folks get their act together on this (and perferably don't link it to
glibc's inefficient lock API)...
as such, i've switch __lock to use malloc's implementation of
lightweight locks, and updated all the users of the code to use an
array with a waiter count for their locks. this should give optimal
performance in the vast majority of cases, and it's simple.
malloc is still using its own internal copy of the lock code because
it seems to yield measurably better performance with -O3 when it's
inlined (20% or more difference in the contention stress test).
|
|
I actually wrote these a month ago but forgot to integrate them. ugly,
probably-harmful-to-use functions, but some legacy apps want them...
|
|
|
|
|
|
I'm not sure if it's legal for wordexp to modify this field, but this
is the only easy/straightforward fix, and applications should not
care. if it's an issue, i can work out a different (but more complex)
solution later.
|
|
|
|
|
|
|
|
|
|
based on patch by sh4rm4. these functions are deprecated; futimens and
utimensat should be used instead in new programs.
|
|
this allows the full range of 64-bit limit arguments even on 32-bit
systems. fallback to the old syscalls on old kernels that don't
support prlimit.
|
|
|
|
note that regardless of the name used, basename is always conformant.
it never takes on the bogus gnu behavior, unlike glibc where basename
is nonconformant when declared manually without including libgen.h.
|
|
|
|
|
|
|
|
setrlimit is supposed to be per-process, not per-thread, but again
linux gets it wrong. work around this in userspace. not only is it
needed for correctness; setxid also depends on the resource limits for
all threads being the same to avoid situations where temporarily
unlimiting the limit succeeds in some threads but fails in others.
|
|
we cannot report failure after forking, so the idea is to ensure prior
to fork that fd 0,1,2 exist. this will prevent dup2 from possibly
hitting a resource limit and failing in the child process. fcntl
rather than dup2 is used prior to forking to avoid race conditions.
|
|
-1, not 0, indicates failure
|
|
previously, a potentially-indeterminate value from we_offs was being
used, resulting in wrong we_wordc and subsequent crashes in the
caller.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
these functions are allowed to be cancellation points, but then we
would have to install cleanup handlers to avoid termination with locks
held.
|
|
clean and simple, but fails when the caller does not have permissions
to open the file for reading or when /proc is not available. i may
replace this with a full implementation later, possibly leaving this
version as an optimization to use when it works.
|
|
|
|
|
|
with datagram sockets, depending on fprintf not to flush the output
early was very fragile; the new version simply uses a small fixed-size
buffer. it could be updated to dynamic-allocate large buffers if
needed, but i can't envision any admin being happy about finding
64kb-long lines in their syslog...
|
|
per the standard, SIGPIPE is not generated for SOCK_DGRAM.
|
|
it actually appears the hacks to block SIGPIPE are probably not
necessary, and potentially harmful. if i can confirm this, i'll remove
them.
|
|
|
|
this eliminates the ugly static buffer in programs that use ptsname_r.
|
|
|
|
|
|
|
|
sadly the C language does not specify any such implicit conversion, so
this is not a matter of just fixing warnings (as gcc treats it) but
actual errors. i would like to revisit a number of these changes and
possibly revise the types used to reduce the number of casts required.
|
|
|
|
|
|
|
|
|
