Replies: 1 comment
-
Adding to the discussion, this change would solve issues like #1220 and #1766 . |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is obviously not simple because of compatibility, but something to keep in mind for the future.
Currently, the
Worker
usesfork()
and theSimpleWorker
doesn't fork. IMHO this is somewhat counter intuitive: forking is a specific behavior with specific consequences and can have significant side effects on third party libraries (probably database connection pools are a good example).My suggestion is to have the non-forking variation to be the default (
Worker
), and then have aForkWorker
which explicitly forks. This may, or may not be the desired behavior, and the user can still chose the best one. I just don't think it's intuitive to have aSimple
worker (what does "simple" mean?), and it's also not intuitive to have a very specific behavior (forking) by default - it does breaks things if you're not careful.This would obviously breaks things, but the adaptation would be extremely simple: if you want the fork, just replace the
Worker
by theForkWorker
(or on the cli maybe justrq worker --fork
), if you don't care about forking, than no changes would be necessary.Probably the best approach would be:
ForkWorker
that is actually just an alias for the current regularWorker
Worker
saying it will change default behavior starting in say, 3 versions (~1.15), and telling people that if they want to keep using the fork, they should replacefrom rq import Worker
tofrom rq import ForkWorker
SimpleWorker
becomes the default worker, and theForkWorker
will be similar as theSimpleWorker
, except with forking.Beta Was this translation helpful? Give feedback.
All reactions