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.
This change was made in order to allow things produced with Odin and using Odin's core library, to not require the LICENSE to also be distributed alongside the binary form.
If allocation of a `^Thread` failed, `create*` now properly return `nil`,
so you can assert on that instead of calling `thread.destroy` on a null pointer, say.
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`.
