Messages in this thread | | | Date | Sun, 18 Sep 2005 13:09:02 -0700 | From | Andrew Morton <> | Subject | Re: Unusually long delay in the kernel |
| |
Alan Stern <stern@rowland.harvard.edu> wrote: > > On Sat, 17 Sep 2005, Andrew Morton wrote: > > > > > That code could be converted to the kthread API btw. > > > > > > Hmph. Near as I can tell, the only changes that would involve are: > > > > > > Converting the thread creation call from kernel_thread to > > > kthread_run. > > > > > > Adding another call to wake the thread up once it has been > > > created. > > > > > > Removing the call to daemonize. > > > > > > There wouldn't be any need to call kthread_stop -- and in fact it wouldn't > > > work, as the thread waits on a semaphore while it is idle (kthread_stop > > > can't cope with things like that). > > > > Well I was assuming that the semaphore would go away as well. Kernel > > threads normally use waitqueues to await more work. > > Some kernel threads have a producer-consumer relationship with their > clients, and it's important that they wake exactly once each time they are > invoked. A semaphore is the natural way to manage such a thread, but the > kthread API isn't set up to handle such things. It's possible to make > this work, by using a manual poor-man's semaphore implementation, but that > seems ridiculous.
OK.
> Would this patch be acceptable?
Well it makes all kthread_stop() callers pass an additional (unused) argument. I'd make kthread_stop() and kthread_stop_sem() real C functions, hide the code sharing within kthread.c.
- 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/
| |