jjb / ruby-clock

A ruby job scheduler which runs jobs each in their own thread in a persistent process.
MIT License
78 stars 1 forks source link

shutdown outside of the handler #41

Closed jjb closed 3 weeks ago

jjb commented 9 months ago

because, i think but haven't totally verified, rufus will create mutexts sometimes which is not allowed in a signal handler

jjb commented 9 months ago

/cc @jmettraux

jmettraux commented 9 months ago

I have never heard that the creation of mutex instances is not allowed in signal handlers.

jjb commented 9 months ago

yep: https://docs.ruby-lang.org/en/master/signals_rdoc.html#label-Unsafe+methods+to+call+in+Signal.trap+blocks

jmettraux commented 9 months ago

"unsafe" != "not allowed".

And the creation of mutexes in rufus-scheduler happens in rufus-scheduler instantiation mostly. I do not think you are instantating rufus-scheduler in a signal handler.

If you are afraid of the contraption becoming unsafe and want a way to bypass any Mutex#synchronize in rufus-scheduler, I'd be happy to help, but please tell me where exactly you need that in an issue.

jjb commented 9 months ago

Thanks for your thoughts @jmettraux - sorry for confusion, I don't think anything needs to be changed in rufus, I just thought you might think this is sort of interesting 😄 and maybe if you had ideas for what calls in rufus might be the problem (or if you are sure it's not). I think the main culprit is, could schedule.shutdown create a mutex lock or mutex synchronize, or invoke a ruby logger (which uses mutex).

jmettraux commented 9 months ago

If my code is the culprit, I'd gladly accept an issue report.

jjb commented 9 months ago

Thanks! but even if it is, i don't think it would be rufus' responsibility to change - was just looping you in in case you had some insights on rufus behavior. all good, hope you're well 😄

jmettraux commented 9 months ago

All good, very busy. I wish you a Happy New Year!