Support testing.set_fail_timeout on UNIX-likes

[Feoramund]

This will require #3468 in order to terminate tests that are stuck in a loop or otherwise preoccupied, but it does register the test as a failure, if it ever yields back to the runner.

Tested on Linux and FreeBSD amd64.

[laytan]

You are not using futexes correctly here. futex_wait accepts the expected value currently at the given futex as its second argument, you are giving it 0 every time now, and when you futex_broadcast you must first write a new value to the futex.

Waiting on a specific futex value has to also be done inside a loop, that actually checks that the value indeed changed to what is wanted.

A good example usage is the One_Shot_Event in core:sync

Odin/core/sync/extended.odin

Line 429 in 8a1e7bb

One_Shot_Event :: struct #no_copy {

you can see it is doing the wait in a loop, and actually changing the value before broadcasting.

Besides that I also don't like that this will run every single test by first creating a new thread and running the test in it, this will slow down testing quite a bit I imagine (I know this is also done on Windows currently, but imo this is not the way to go in the long run), but we can probably look at improving that later.

[Feoramund]

What would be the alternative solution? Creating threads at testing.runner that can be passed each test and replaced as necessary if they timeout?

[laytan]

What would be the alternative solution? Creating threads at testing.runner that can be passed each test and replaced as necessary if they timeout?

That would be ideal I think, some kind of thread pool (probably not the one in the threads package) that tests get ran on.

But, to be clear, I am not asking you to do that here, we can look at that later too.

[Feoramund]

Does the thread pool implementation in the threads package need improvement, or are there special requirements for a test runner thread pool? I had a look for issues regarding the thread pool and could only find #2746.

[laytan]

Does the thread pool implementation in the threads package need improvement, or are there special requirements for a test runner thread pool? I had a look for issues regarding the thread pool and could only find #2746.

No I think the thread pool is pretty good there, I just mean you'd at least need some timeout mechanism in it right, but you might be able to built that on top of it, idk.

[Feoramund]

Closing in favor of #3646.