The pre-apply damage thread may be running when we destroy a terminal instance, and we need to wait for it to finish before destroying the underlying buffer.
c291194a4e did this, but failed to realize the thread may get re-started in the roundtrips done later in wayl_win_destroy(); after the wait added in c291194a4e, we unmap all surfaces (including the main grid), and roundtrip. This means the compositor will release the currently active buffer, and that means we will trigger the pre-apply damage thread on it. This introduces a race, where wayl_win_destroy() may reach its shm_purge() calls before the pre-apply damage thread has finished. That typically causes foot to crash.
Closes #2288
The pre-apply damage thread may be running when we destroy a terminal instance, and we need to wait for it to finish before destroying the underlying buffer.
c291194a4e593bbbb91420e81fa0111508084448 did this, but failed to realize the thread may get re-started in the roundtrips done later in `wayl_win_destroy()`; after the wait added in c291194a4e593bbbb91420e81fa0111508084448, we unmap all surfaces (including the main grid), and roundtrip. This means the compositor will release the currently active buffer, and that means _we_ will trigger the pre-apply damage thread on it. This introduces a race, where `wayl_win_destroy()` may reach its `shm_purge()` calls before the pre-apply damage thread has finished. That typically causes foot to crash.
Closes #2288