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

Fix race condition in once #77

Merged
merged 1 commit into from Oct 8, 2020
Merged

Conversation

forslund
Copy link
Contributor

@forslund forslund commented Oct 7, 2020

This is a naive locking approach to the issue reported in #76

This PR adds a check in the once-wrapper that listener method is still registered before removing. To ensure atomic execution a lock is added around removals of listeners.

Copy link
Owner

@jfhbrook jfhbrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This loops pretty good! I think beyond stylistic things what I'd like to see implementation-wise is the lock used in the other non-removal spots where things are mucked around with, particularly in _add_event_handler and _call_handlers.

It would also be great if we can add a test for the sync handler, something like:

ee = EventEmitter()

@ee.once("event")
def remove_self():
    ee.remove_listener("event", remove_self)

ee.emit("event")

This should crash before this change but work afterwards.

Thanks for taking a look at this! I really appreciate it, it's saving me a lot of work.

pyee/_base.py Outdated
@@ -38,6 +39,7 @@ def on_error(message):
"""
def __init__(self):
self._events = defaultdict(OrderedDict)
self.lock = Lock()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's privatize this property 💰

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed it to _lock

pyee/_base.py Show resolved Hide resolved
pyee/_base.py Show resolved Hide resolved
@forslund
Copy link
Contributor Author

forslund commented Oct 7, 2020

Good comments all around will try to get an update done tonight / tomorrow

1 similar comment
@forslund
Copy link
Contributor Author

forslund commented Oct 7, 2020

Good comments all around will try to get an update done tonight / tomorrow

@jfhbrook
Copy link
Owner

jfhbrook commented Oct 7, 2020

Cool! Any work you do on this is much appreciated, and if you run out of steam I can always take and run with your work.

@forslund
Copy link
Contributor Author

forslund commented Oct 8, 2020

The testcase became a bit more convoluted since the removal is done before the target function is called (I guess to minimize the risk of this kind of race). Let me know if the solution is too hacky.

Copy link
Owner

@jfhbrook jfhbrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove the test - you're right that's really hairy - and then I'm happy to merge this. Nice work!

if event in self._events and f in self._events[event]:
self._remove_listener(event, f)
else:
return None
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah OK I see what you mean here. Interesting, I wouldn't have expected the edge case we saw given this ordering (though in a threaded context without locks it makes sense). Guess I should have looked more closely!

Mulling this over, I think shrugging and returning None is OK, because if the edge case we're talking about triggers it probably means that the handler has either already been called or was intentionally removed between the function executing and the lock yielding.

@@ -203,6 +204,21 @@ def once_handler(data):
assert ee._events['event'] == OrderedDict()


def test_once_remove_race():
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oof, yeah, OK, I see what you mean with this test. I wish there was a sensible way to test this, but I think that given what we have here it's too hairy to implement what we had in mind. My vote is to remove this test and shrug.

Add check that listener method is still registered before removing. To
ensure atomic execution a lock is added around removals of listeners.
@forslund
Copy link
Contributor Author

forslund commented Oct 8, 2020

I dropped the test commit from the branch and squashed the remaining two commits into a single one. should be good to go now.

Copy link
Owner

@jfhbrook jfhbrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent. I'll try to do a merge and release tonight! This weekend at the latest.

@jfhbrook jfhbrook merged commit dc309b2 into jfhbrook:master Oct 8, 2020
@forslund forslund deleted the locked-removal branch October 8, 2020 19:51
@jfhbrook
Copy link
Owner

jfhbrook commented Oct 8, 2020

Released in 8.1.0. Thanks!

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

Successfully merging this pull request may close these issues.

None yet

2 participants