Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

timers should be Send #1

Open
tinaun opened this issue Feb 14, 2019 · 3 comments
Open

timers should be Send #1

tinaun opened this issue Feb 14, 2019 · 3 comments

Comments

@tinaun
Copy link
Owner

tinaun commented Feb 14, 2019

test and make sure of this.

@kbleeke
Copy link

kbleeke commented Feb 26, 2019

Hi,
I was looking at the Linux implementation and I was wondering why it was explicitly made not Send.
After further investigation it seems that according to the SIGNAL-SAFETY(7), it is not safe to call nonreentrant functions in signal handler. This would Mutex::lock(), I believe.
I don't know, if this would cause problems with the other timer backends, but have you thought about replacing the Mutex solution with AtomicWaker (and possibly AtomicBool for done):

#[derive(Debug)]
pub (crate) struct TimerState {
    wake: AtomicWaker,
    done: AtomicBool,
}

and then simply Arc<TimerState> instead of Arc<Mutex<TimerState>>

@PvdBerg1998
Copy link
Contributor

Bumped into this problem. The most important part is that the Windows impl is Send, but Linux isn't, so on my dev machine it was working but when I tried to compile it on Linux suddenly it doesn't.

@withoutboats
Copy link

Yea it seems like the right solution is to use AtomicWaker, which is what other event sources (like tokio and romio) all do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants