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

Message queue: block for worker stop #221

Closed

Conversation

isaacseymour
Copy link
Contributor

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 and others added 10 commits February 1, 2019 14:58
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).
@ptaoussanis
Copy link
Member

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).
@isaacseymour isaacseymour deleted the mq-block-for-worker-stop branch May 14, 2019 14:06
@isaacseymour
Copy link
Contributor Author

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants