pthreadpool: add a comment about a further optimization in pthreadpool_tevent_job_des...

This seems to be a really rare race, it's likely that the immediate
event will still trigger and cleanup.

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>

diff --git a/lib/pthreadpool/pthreadpool_tevent.c b/lib/pthreadpool/pthreadpool_tevent.c
index 3b502a7cc5a3cdb8080a8afc97946452ada796cf..94b6b9ded8ff5e5718c899ecfe0d5c157dda10d8 100644 (file)
--- a/lib/pthreadpool/pthreadpool_tevent.c
+++ b/lib/pthreadpool/pthreadpool_tevent.c
@@ -491,6 +491,23 @@ static int pthreadpool_tevent_job_destructor(struct pthreadpool_tevent_job *job)
                TALLOC_FREE(job->im);
        }
 
+       /*
+        * TODO?: We could further improve this by adjusting
+        * tevent_threaded_schedule_immediate_destructor()
+        * and allow TALLOC_FREE() during its time
+        * in the main_ev->scheduled_immediates list.
+        *
+        * PTHREAD_TEVENT_JOB_THREAD_FENCE(job);
+        * if (state->needs_fence.signaled) {
+        *       *
+        *       * The signal function is completed
+        *       * in future we may be allowed
+        *       * to call TALLOC_FREE(job->im).
+        *       *
+        *      TALLOC_FREE(job->im);
+        * }
+        */
+
        /*
         * pthreadpool_tevent_job_orphan() already removed
         * it from pool->jobs. And we don't need try