Introduce MainloopWaker for thread-safe pa_mainloop_wakeup#67
Open
orestisfl wants to merge 1 commit intojnqnfe:masterfrom
Open
Introduce MainloopWaker for thread-safe pa_mainloop_wakeup#67orestisfl wants to merge 1 commit intojnqnfe:masterfrom
MainloopWaker for thread-safe pa_mainloop_wakeup#67orestisfl wants to merge 1 commit intojnqnfe:masterfrom
Conversation
the standard `Mainloop` is `!Send` (it's wrapped in `Rc`), so today the only way for downstream code to interrupt a blocking `Mainloop::iterate(true)` from another thread is to reach into `_inner`, grab the raw `*mut pa_mainloop`, and invoke `pa_mainloop_wakeup` via hand-rolled `unsafe extern "C"`. that single C function is documented as thread-safe (it just writes a byte to the mainloop's internal self-pipe), so a small safe abstraction is worthwhile. * `MainloopWaker`: a `Send + Sync + Clone` handle wrapping the call. * `Mainloop::waker()`: hands out a waker tied to this mainloop. the handle stores the mainloop pointer behind a `Mutex<*mut MainloopInternal>`. `MainloopWaker::wakeup` holds the mutex across `pa_mainloop_wakeup`; `Mainloop::drop` nulls the pointer under the same mutex before the underlying `pa_mainloop` is freed. wakers therefore never observe a freed pointer and become no-ops once the mainloop is gone. `Rc<MainloopInner>` is left unchanged: the rest of the standard mainloop API is `!Send` by design, so the `Arc`-backed sidecar is scoped to the one operation that genuinely is cross-thread. Came up in JakeStanger/ironbar#875
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
the standard
Mainloopis!Send(it's wrapped inRc), so today the only way for downstream code to interrupt a blockingMainloop::iterate(true)from another thread is to reach into_inner, grab the raw*mut pa_mainloop, and invokepa_mainloop_wakeupvia hand-rolledunsafe extern "C". that single C function is documented as thread-safe (it just writes a byte to the mainloop's internal self-pipe), so a small safe abstraction is worthwhile.MainloopWaker: aSend + Sync + Clonehandle wrapping the call.Mainloop::waker(): hands out a waker tied to this mainloop.the handle stores the mainloop pointer behind a
Mutex<*mut MainloopInternal>.MainloopWaker::wakeupholds the mutex acrosspa_mainloop_wakeup;Mainloop::dropnulls the pointer under the same mutex before the underlyingpa_mainloopis freed. wakers therefore never observe a freed pointer and become no-ops once the mainloop is gone.Rc<MainloopInner>is left unchanged: the rest of the standard mainloop API is!Sendby design, so theArc-backed sidecar is scoped to the one operation that genuinely is cross-thread.Came up in JakeStanger/ironbar#875