Re: Unusually long delay in the kernel

[Andrew Morton <akpm@osdl.org>]

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.