No Description Provided

attachment
0001-Ticket-51-Job-rearm-should-ignore-if-ns_persist-is-s.patch

Might be a silly quetion...

You added to work_q_notify to update_event:
{{{
a b update_event(ns_job_t job)
264 } else {
265 / It's a "run now" job. /
266 work_q_notify(job);
}}}
The event_q_notify calls update_event in case being fun from the same thread.
{{{
event_q_notify(ns_job_t job)
if (PR_GetCurrentThread() == tp->event_thread) {
/ If we are being run from the same thread as the event
loop thread, we can just update the event here /
update_event(job);
}}}
There's no chance to go into an endless call loop / stackoverflow?

No. The event_q only every updates the work_q. Never the work_q to the event_q.

In this scenario, two things can happen.

We are NOT the event thread, and we schedule a job with ns_job_rearm. This calls event_q_notify, which then puts the event into the event_q. The event loop itself will then find this in get_new_event_requests(), and will call update_event, pushing the job to the work queue to be processed.

In the case we ARE the event thread, we don't need to wait for the event loop to come around, we ARE the event loop. We can just call update event straight away. Once the job moves to the work_q it will be collected by a thread in the worker_thread_func() loop.

So there are no loops or races here!

In fact, a future ticket will likely be to cut out this middle man. When we call ns_job_rearm, it will "pre-route" the job to the event_q or the work_q based on the flags, as ns_job_modify does now.

Ok. Thanks for your explanation!

commit 829b684
Compressing objects: 100% (25/25), done.
Writing objects: 100% (27/27), 50.14 KiB | 0 bytes/s, done.
Total 27 (delta 20), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/nunc-stans.git
7ef7ec1..7a4ce78 master -> master