On Mon, Sep 16, 2024 at 12:24 AM Gary Guo <gary@xxxxxxxxxxx> wrote:
>
> On Sun, 15 Sep 2024 14:31:34 +0000
> Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote:
> > + /// Register this [`PollTable`] with the provided [`PollCondVar`], so that it can be notified
> > + /// using the condition variable.
> > + pub fn register_wait(&mut self, file: &File, cv: &PollCondVar) {
> > + if let Some(qproc) = self.get_qproc() {
> > + // SAFETY: The pointers to `file` and `self` need to be valid for the duration of this
> > + // call to `qproc`, which they are because they are references.
> > + //
> > + // The `cv.wait_queue_head` pointer must be valid until an rcu grace period after the
> > + // waiter is removed. The `PollCondVar` is pinned, so before `cv.wait_queue_head` can
> > + // be destroyed, the destructor must run. That destructor first removes all waiters,
> > + // and then waits for an rcu grace period. Therefore, `cv.wait_queue_head` is valid for
> > + // long enough.
> > + unsafe { qproc(file.as_ptr() as _, cv.wait_queue_head.get(), self.0.get()) };
> > + }
>
> Should this be calling `poll_wait` instead?
>
> > +#[pinned_drop]
> > +impl PinnedDrop for PollCondVar {
> > + fn drop(self: Pin<&mut Self>) {
> > + // Clear anything registered using `register_wait`.
> > + //
> > + // SAFETY: The pointer points at a valid `wait_queue_head`.
> > + unsafe { bindings::__wake_up_pollfree(self.inner.wait_queue_head.get()) };
>
> Should this use `wake_up_pollfree` (without the leading __)?
For both cases, that would require a Rust helper. But I suppose we could do it.
Alice
