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

Enhancement: add signals #219

Closed
abompard opened this issue Mar 3, 2017 · 0 comments
Closed

Enhancement: add signals #219

abompard opened this issue Mar 3, 2017 · 0 comments

Comments

@abompard
Copy link
Contributor

abompard commented Mar 3, 2017

I think it would be a simple and very useful feature if django-q could send signals at some point of its operation. I'm thinking of the following signals:

  • pre_enqueue: would be run in the tasks.async() function before the task is sent to the broker, and would receive the whole task object.
  • pre_execute: would be run by the worker before executing the function.

Those could be simple Django signals.

The reason I'm asking for this is I'm trying to implement a "singleton" task, a task that would guarantee only one (or zero) instance of itself in the queue. For that I store a lock in the cache when the task is enqueued and release it when the task is run. If a lock is found, the enqueue operation isn't done a second time, instead the previous id is return. I could wrap the async function or subclass the Async class but it's hard to do properly because function arguments are mixed with task options, and the function must remain pickleizable.

Having signals would make that much easier, I could lock and unlock in the cache using those signals, and just subclass Async to check for the lock in run().

abompard added a commit to abompard/django-q that referenced this issue Mar 3, 2017
abompard added a commit to abompard/django-q that referenced this issue Mar 3, 2017
@abompard abompard mentioned this issue Mar 3, 2017
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

1 participant