Deadlock detection fails if threads are transitively waited for

[Sipkab]

Given the following scenario:

1. The build task T is being invoked.
2. The task starts a new thread W.
3. The thread W starts to wait for other task D. (However, the task D is never started.)
4. The build task attempts to wait for W.
5. The execution deadlocks, as the waiting for D will never complete. However, the deadlock is not detected by the build system.

The build execution can be stopped by manually interrupting the execution thread. This can be done inside an IDE, however, it's unclear for command line execution.

This behaviour can be distruptive in case of CI builds, as the build will never stop.

Workaround

1. Don't configure the build to deadlock. It can be usually avoided in a straightforward way.
2. Don't implement tasks that concurrently perform waiting for threads and waiting for tasks.

Solution

In general, advising task authors to perform the waiting for input task first, and do the work last should be enough. This is already the recommended workflow for build tasks implementations, therefore there won't be much change.

Another solution is to allow the above transitive waiting, but require the build task authors to delegete the Thread.join call through the build system. In this case we can detect the number of waiting threads.

Notice

There's a chance that this issue may remain open for a prolonged amount of time and be a known bug of saker.build. Generally, this is a rarely occurring bug that can be mitigated by proper implementations of the build tasks. The delegating through build system solution is still a viable partial solution that has a high chance to be implemented.