ns_job_modify is meant to take a job and alter it to be able to work in a different way.
There are so many issues with this function. Most of them are involved in the way that the event framework works, and how I have changed NS to work for safety.
The biggest issue is that with ns_job_modify, you can alter a job, but without that being reflected in the event framework. This is because we don't want to automatically rearm the job when we make the change. However altering the job in the ev framework acts like an arming, so you can end up with an event occuring when the job is in the wrong state.
Additionally, a huge flaw in the design of this, is that the existing event's are not removed on mod! So you can have MULTIPLE events triggering a job to execute, even if you intended to remove them. This meant that the ns_job_modify to DISABLE a job actually did nothing, and the job was still responding to events even though it was not meant to.
It also means you can end up with the job queued in the event framework multiple times, which can cause some excellent state machine violations.
While on one hand I could fix this, I also don't want to. It's a complicated mess. It's fragile. If you want to disable a job, delete it. If you want to change a job, delete it and add a new one with the same FD. There are too many land mines here, and ways to make mistakes.
As a result, I'm going to remove ns_job_modify and the NS_JOB_DISABLE flag. This will entail another change to Directory Server to allow it to function with NS again.
attachment 0001-Ticket-64-Remove-ns_job_modify.patch
commit 59aa6738ab17fac5a40deb6ebb85c187d797c3ee Compressing objects: 100% (33/33), done. Writing objects: 100% (33/33), 9.68 KiB | 0 bytes/s, done. Total 33 (delta 25), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/nunc-stans.git 9dacc22..59aa673 master -> master