Revert "core: dispatch on exit instead of roundtrip"

[PaideiaDilemma]

This reverts commit 2c7027d. Without the roundtrip it was possible that session_lock_surface_destroy gets called before unlock_and_destroy is processed.

fixes #107

[pdf]

I've not been able to reproduce the RSOD with this change, and previously could do so within ~10 attempts. Sometimes hyprlock takes a number of seconds to return on exit now, I suspect that when that occurs it would previously have triggerred the RSOD.

[vaxerski]

on the other hand with it some people get freezes.

[pdf]

For reference this appears to be the related issue: #87

We definitely need to synchronize somehow - hyprlock can never be allowed to destroy the surface before the unlock signal is sent.

I don't know enough about wayland etc to be of much use here, but the docs for ext_session_lock_v1_unlock_and_destroy have this to say:

Note that a correct client that wishes to exit directly after unlocking
the session must use the wl_display.sync request to ensure the server
receives and processes the unlock_and_destroy request. Otherwise
there is no guarantee that the server has unlocked the session due
to the asynchronous nature of the Wayland protocol. For example,
the server might terminate the client with a protocol error before
it processes the unlock_and_destroy request.

The docs for wl_display suggest that "a module that runs using its own proxy queue that needs to do display roundtrip must wrap the wl_display proxy object before sending the wl_display.sync request", which is what wl_display_roundtrip appears to do, but I'm not certain if that requirement applies here.

The docs for wl_display_roundtrip/wl_display_roundtrip_queue do mention that they're not thread-safe and can deadlock under some conditions.

Can we perhaps just call wl_display_sync directly, and use the returned callback to synchronize? I don't write C++ unfortunately.

If that's not an option then I suspect what's required here is to continue calling wl_display_roundtrip, but add a mutex around this and whatever read operations may trigger the deadlock.

[vaxerski]

I guess I'll merge this.

This is called from the main thread so it should be safe

[pdf]

I wonder if this might be relevant, from the docs for wl_display_dispatch_queue, which is used internally by wl_display_roundtrip:

In a multi threaded environment, do not manually wait using poll() (or equivalent) before calling this function, 
as doing so might cause a dead lock. If external reliance on poll() (or equivalent) is required, see 
wl_display_prepare_read_queue() of how to do so.

I see that we're polling the display for events in a thread at

hyprlock/src/core/hyprlock.cpp

Line 326 in a7ec195

int ret = poll(pollfds, 1, 5000 /* 5 seconds, reasonable. It's because we might need to terminate */);

Again though, all of this is quite outside my wheel-house, so maybe this is unrelated and not relevant.

[vaxerski]

idk either tbh lol

[PaideiaDilemma]

I think this is not really relevant, since the event loop is single threaded. The poll thread might get "stray" poll events but that should not matter.

The freezes come from an unfortunate ordering where the poll thread waits for the eventLoopMutex. Then the main thread sets m_bTerminate and and then the poll thead polls again, which causes a 5 second freeze.