[Fedora-directory-devel] Please review: [Bug 195305] make new_task() non-static & [Bug 195307] task registration by plugins is wiped by task_init()

[Noriko Hosoi]

Summary: make new_task() non-static

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195305

Problem description:
The current prototype for task.c:new_task() is:
static Slapi_Task *new_task(const char *dn)

Can you make it non-static?  new_task() is used to register a new task request,
eg cn=mytask_200606091405, cn=mytask, cn=tasks, cn=config.  new_task() is a
pretty simple function and it could be recreated by people writing custom tasks,
except that to register a new task request one needs access to the global task
list and the mutex around it.  Currently new_task() is the only (indirect)
access to those objects for code outside libslapd.  So we need either a getter
function for the mutex and global task list, or new_task() should be callable
from plugin libraries.
      

------- Additional Comments From nhosoi at redhat.com  2006-12-13 18:26 EST -------
Created an attachment (id=143579)
 --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=143579&action=view)
cvs diffs (

Thank you, Ulf, for your response!  

Here's the proposal...

Files:
 slapi-plugin.h
 slapi-private.h
 mapping_tree.c
 task.c

Change description:
Expose new_task and destroy_task as slapi_new_task and slapi_destroy_task:
+/*
+ * slapi_new_task: create new task, fill in DN, and setup modify callback
+ * argument:
+ *	dn: task dn
+ * result:
+ *	Success: Slapi_Task object
+ *	Failure: NULL
+ */
+Slapi_Task *slapi_new_task(const char *dn);
+
+/* slapi_destroy_task: destroy a task
+ * argument:
+ *	task: task to destroy
+ * result:
+ *	none
+ */
+void slapi_destroy_task(void *arg);

We also have to open the task status macros:
+/* task states */
+#define SLAPI_TASK_SETUP	 0
+#define SLAPI_TASK_RUNNING	 1
+#define SLAPI_TASK_FINISHED	 2
+#define SLAPI_TASK_CANCELLED	 3

And task support functions:
+int slapi_task_register_handler(const char *name, dseCallbackFn func);
+void slapi_task_status_changed(Slapi_Task *task);
+void slapi_task_log_status(Slapi_Task *task, char *format, ...)



------------------------------------------------------------------------

Summary: task registration by plugins is wiped by task_init()

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195307

Problem description:
main() calls task_init() after plugin_startall().  I think that order is
necessary, except task_init() calls cleanup_old_tasks().  Therefore any task
subtrees in the DSE that were added as part of task registration by plugins are
deleted.

As a workaround I'm finding some way to register my task at a later point, maybe
with an eq delay or triggered from another common plugin callback like
SLAPI_PLUGIN_PRE_SEARCH_FN maybe - I'm open to suggestions.

But eventually, maybe it would be good to rework the way this works somehow.  I
think the community would dig being able to write plugins for custom tasks and
it's a bit cumbersome and undocumented at the moment.

 ------- Additional Comments From nhosoi at redhat.com  2006-12-13 18:08 EST -------
Created an attachment (id=143572)
 --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=143572&action=view)
cvs diffs (slapi-private.h, main.c, task.c)

Files:
 slapi-private.h
 main.c
 task.c

Change description:
I agree with Nathan that we don't have "to have one central cleanup
function to cleanup any type of task entry that may be hanging around" for the
current task usage.  I'm a little worried if we expose the interface and allow
users to add task plugins, then we may have more chances to see such leftovers.
 So, cleaning up all the tasks belonging to cn=tasks,cn=config first could be
more meaningful.

I renamed the cleanup function cleanup_old_tasks to task_cleanup and made it
available just for the server ns-slapd (it's declared in slapi-private.h) and
call it before plugin_startall in main.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20061213/71a26ee6/attachment.bin>