-
-
Notifications
You must be signed in to change notification settings - Fork 132
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
Message queue: block for worker stop #221
Closed
isaacseymour
wants to merge
10
commits into
taoensso:master
from
isaacseymour:mq-block-for-worker-stop
Closed
Message queue: block for worker stop #221
isaacseymour
wants to merge
10
commits into
taoensso:master
from
isaacseymour:mq-block-for-worker-stop
Conversation
This file contains 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
Would be nice to have this in Redis core, but doesn't look like it's likely to happen. Ref. redis/redis#542 Note that there's another Lua implementation floating around (https://redisgreen.net/library/hmsetnx.html), but that doesn't account for a pre-existing hash key without the given fields.
Time+space optimization for a common case (writing serialized `nil`s), avoiding Nippy overhead.
When running the `mq/stop`, deref all the worker-loop futures. This is helpful if, for example, the worker processing depends on other parts of a component system. At the moment I'm getting errors where the component system shuts down without being aware of the fact that there are still some worker threads running, meaning that the workers try to access closed resources (for example).
This looks good, merging now manually- thanks! |
ptaoussanis
pushed a commit
that referenced
this pull request
May 11, 2019
…acseymour) When running the `mq/stop`, deref all the worker-loop futures. This is helpful if, for example, the worker processing depends on other parts of a component system. At the moment I'm getting errors where the component system shuts down without being aware of the fact that there are still some worker threads running, meaning that the workers try to access closed resources (for example).
ptaoussanis
pushed a commit
that referenced
this pull request
May 11, 2019
…acseymour) When running the `mq/stop`, deref all the worker-loop futures. This is helpful if, for example, the worker processing depends on other parts of a component system. At the moment I'm getting errors where the component system shuts down without being aware of the fact that there are still some worker threads running, meaning that the workers try to access closed resources (for example).
ptaoussanis
pushed a commit
that referenced
this pull request
May 11, 2019
…acseymour) When running the `mq/stop`, deref all the worker-loop futures. This is helpful if, for example, the worker processing depends on other parts of a component system. At the moment I'm getting errors where the component system shuts down without being aware of the fact that there are still some worker threads running, meaning that the workers try to access closed resources (for example).
Yay, thank you! Do you have a plan for releasing a new version? I'd love to delete all my hacky patching 😄 |
ptaoussanis
pushed a commit
that referenced
this pull request
Sep 8, 2019
…acseymour) When running the `mq/stop`, deref all the worker-loop futures. This is helpful if, for example, the worker processing depends on other parts of a component system. At the moment I'm getting errors where the component system shuts down without being aware of the fact that there are still some worker threads running, meaning that the workers try to access closed resources (for example).
ptaoussanis
pushed a commit
that referenced
this pull request
Oct 18, 2019
When running the `mq/stop`, deref all the worker-loop futures. This is helpful if, for example, the worker processing depends on other parts of a component system. At the moment I'm getting errors where the component system shuts down without being aware of the fact that there are still some worker threads running, meaning that the workers try to access closed resources (for example).
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.
When running the
mq/stop
, deref all the worker-loop futures.This is helpful if, for example, the worker processing depends on other
parts of a component system. At the moment I'm getting errors where the
component system shuts down without being aware of the fact that there
are still some worker threads running, meaning that the workers try to
access closed resources (for example).