> There have been ambitious attempts to do a nice "thread
> creation and stopping" interface before. Given the delicate logic
> involved in shutting threads down, I think this makes sense. Maybe
> something like:
>
> /* Struct which identifies a kernel thread, handed to creator and
> thread. */
> struct kthread
> {
> int pid;
> int should_die; /* Thread should exit when this is set. */
>
> /* User supplied arg... */
> void *arg;
> };
>
> struct kthread *create_thread(int (*fn)(struct kthread*), void *arg,
> unsigned long flags,
> const char *namefmt, ...);
> void cleanup_thread(struct kthread *);
>
> create_thread would use keventd to start the thread, and stop_thread
> would tell keventd to set should_die, wmb(), wake it up, and
> sys_wait() for it.
>
> Thoughts?
> Rusty.
Why using keventd? Personally I'd prefer a synchronous thread start/stop,
particularly with the thread living in a module.
Maybe some generalisation of:
static DECLARE_WAIT_QUEUE_HEAD(wq_kthread);
static struct completion kthread_died;
static int should_die;
static int my_kthread(void *started)
{
daemonize("my_kthread");
complete((struct completion *)started);
while (!should_die) {
/* sleep for wq_kthread and do requested stuff */
}
complete_and_exit(&kthread_died, 0);
/* never reached */
return 0;
}
int my_kthread_create(...)
{
DECLARE_COMPLETION(started);
int pid;
should_die = 0;
init_completion(kthread_died);
pid = kernel_thread(my_kthread, &startup, CLONE_FS|CLONE_FILES);
if (pid <= 0)
return -EAGAIN;
wait_for_completion(&started);
return pid;
}
void my_kthread_join(...)
{
should_die = 1;
wake_up(&wq_kthread);
wait_for_completion(&kthread_died);
}
Assuming the create/join things are called from module init/exit path this
eliminates the need to bump the module refcnt.
To make this more generic I think it would be sufficient to move the
start/exit completions into your struct kthread.
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/