This fixes several issues in ResourceLoader
* When waiting on resources being loaded on the main thread it is
possible that the resource was waiting on the message queue. Flush
the message queue in this situation. This was an existing bug.
* When re-starting a load for deadlock-prevention reasons, and this
type of resource has nested resources and uses resource changed
connections we end up with references to resourcese being deleted
as duplicates in the dependent task. We now keep a reference to these
resources for the duration of the dependent load task. This closes
the race but does not entirely eliminate it during intial import.
This is an existing bug seemingly specific to TileSetSource but there
might be others.
* When threads are waiting during teardown we ended up deadlocking
because the waiting thread would never end up completing. This is a
bug introduced by f63ab5f
* When a thread loading a resource ends up calling back into the
WorkerThreadPool to wait cooperatively it expects that other threads
complete, or new requests are made, so that work moves forward. If
all OTHER threads end up blocked by the WorkerThreadPool waiting
thread then no forward progress can be made anymore. We now solve
this problem by yielding whenever we are blocked by another task. We
wake up each every task whenever any progress is made to see if
further progress can be made. This is a bug introduced by f63ab5f
* When dependencies get introduced while loading it is possible to form
a dependency cycle. Normally this isn't a problem but when all
threads are already waiting when the cycle is introduced no forward
progress can be made anymore. We now break such cycles. This is a bug
introduced by f63ab5f
HP van Braam
374102cfbe