I know I left a note there about deadlocks but it doesn't seem to happen
anymore, especially now that the test runner creates cancellation points.
Also, what was this `can_set_thread_cancel_state` for? It does not make
sense to me that it enables cancellation, and then does it again later.
With the comment it seems like it should be `.DISABLE` to first disable
and then wait for the thread to start. But even that seems weird, why
do you need to do that? I removed it.
afed3ce removed the sys/unix package and moved over to sys/posix, it has
new bindings for the pthread APIs but should have been equivalent (not).
8fb7182 used `CANCEL_ENABLE :: 0`, `CANCEL_DISABLE :: 1`, `CANCEL_DEFERRED :: 0`, `CANCEL_ASYNCHRONOUS :: 1` for Darwin, while the
correct values are `1`, `0`, `2` and `0` respectively (same mistake was made for
FreeBSD in that commit).
What this meant is that the
`pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS)` was not actually
successful, but because the error wasn't checked it was assumed it was.
It also meant `pthread_setcancelstate(PTHREAD_CANCEL_ENABLE)` would
actually be setting `PTHREAD_CANCEL_DISABLE`.
The code in this PR restores the behaviour by now actually deliberately
setting `PTHREAD_CANCEL_DISABLE` and not setting
`PTHREAD_CANCEL_ASYNCHRONOUS` which was the previous behaviour that does
actually seem to work for some reason.
(I also fixed an issue in fmt where `x` would use uppercase if it was a
pointer.)
One less value to store, and it should be less of a hack too.
Semaphores will not wait around if they have the go-ahead; they depend
on an internal value being non-zero, instead of whatever was loaded when
they started waiting, which is the case with a `Cond`.
Updated core with some path related functions and did some minor code cleanup.
Most of the standard library function is just a matter of copy what is there for the other BSDs.
