Retry calls that raise file system errors during cleanup
If a test case mounts user-space (puffs/fuse) file systems or spawns
server processes that create pid files, the termination of the
corresponding processes does not guarantee that the file system is
left in a consistent state immediately. The cleanup routines of both
components (file systems and daemons) may still be running.
This situation causes a race condition between the termination of the
auxiliary processes and our own file system cleanup: the file system
calls performed from within the cleanup routine may raise errors
because the file system is still changing underneath. (E.g. we first
enumerate the contents of a directory and get file X, but when we
attempt to delete file X, it may be gone.)
Deal with this by retrying failing file system calls a few times and
ignoring "expected" errors before giving up.
- Update TCB for the initial thread in pthread__initthread, not
pthread__init to get it valid as soon as possible.
- Don't overwrite the pt_tls field in pthread__initthread.
- Don't deallocate pt_tls in pthread__scrubthread. This worked more by
chance than by design.
- Handle freeing the TLS area in pthread_create after removing the
thread instance from the dead queue.
If the argument provided to pidfile(3) contains a '/', then the value is
considered to be an absolute/relative path and the pid file is created
in the given location.
Otherwise, pidfile(3) behaves as before and treats the provided value as
a basename to construct a pid file in /var/run/<basename>.pid. This means
that to create a pid file named "foo.pid" in the current directory, one
must specify "./foo.pid".
At least PROM's _getenv() on 3MIN doesn't preserve CALLFRAME_S0(s0)
and prom_findcons() returns bogus console after mips64 merge.
XXX: I wonder if it's safe to use CALLFRAME_S0(sp) (== 0(sp)) on O32/O64..
Use a simple generation count instead and restart looking for work if it
changed (e.g. due to an dlopen call from an init function).
Leave the possible dlclose() race for now.
The prior definition of sievert was, as far as I can tell, entirely wrong.
Caution: while "gray" and "sievert" have the same dimensionality,
they're not interchangeable -- you need to multiply by a fudge factor
that varies depending on the type of radiation and the tissue it's
affecting. (Dimensional analysis is often not a substitute for knowing
what you're doing.)
It would be nice if units had a way to warn users when they're trying
to do something that doesn't make sense, since there are lots of ways
to do so, but it doesn't, and it wouldn't be easy to arrange in the
general case.
