threads: make more of this API cancellation safe

It's desirable to be able to cancel a rendering loop thread
used in librototiller callers, which will necessarily use these
functions.

When the cancellation originates from a GUI thread, which then
joins on the rendering loop thread being cancelled, this blocks
the GUI thread until the rendering loop thread realizes the
cancellation and exits.

But the GUI thread is likely party to the machinery of consuming
fb pages being produced by librototiller, throwing them
on-screen, and making previously visible pages available for
reuse.

The rendering loop thread blocks on waiting for that making pages
available step, to have space for rendering a new frame into.
This creates a circular dependency, and when the GUI thread is
stuck in the cancel+join of the render loop thread, this
establishes potential for deadlock when there's no extra page
already available, and the GUI thread can't service its event
loop to flip a page.

Thread cancellation is the escape hatch for such situations,
which is why cancellation can't be disabled across the critical
section of librototiller calls and reenabled+polled at the top of
the render loop thread.  We *need* cancellation to wake up and
break out of all the cancellation points within that critical
section, so they don't deadlock in this scenario.  They need to
wake up, cleanup any held locks, and the calling thread exit so
the join may finish and life goes on.

Hence, put these unlocks in cleanup handlers so callers can
cancel them without leaking held locks.

0 files changed, 0 insertions, 0 deletions