> On Sat, 13 Jan 2007, Iain Hibbert wrote:
> 
> > On Sat, 13 Jan 2007, YAMAMOTO Takashi wrote:
> >
> > > once callout_setwork() is called on a callout,
> > > callout_schedule() is only legal operation on the callout.
> >
> > callout_schedule() cannot be called multiple times, either..
> 
> I think that these issues would go away, if callout managed its own
> kthread, instead of utilising workqueue to do that?
> 
> (So, hang the callout on a callout CIRCQ instead of work queue)

i don't think they are issues.
again, i don't think it's a good idea to make primitives like this have
rich functionalities.  we should learn from lockmgr.

> I see another issue though, in that if you want a callout in a thread, it
> still does not mean you can take locks or do IO, because sleeping would
> block the callout kthread.

i don't think it's a problem unless it sleeps "very long".

> I wonder if it would be better if the caller was responsible for their own
> workqueue, but you could mark the callout as a workqueue/work to be queued
> instead of a function/arg to be called?
> 
> iain

is it worth to have an api for it?
once you created your own workqueue, there are not many things left to do.
just schedule a function to do workqueue_enqueue by callout_reset,
and you've done.

YAMAMOTO Takashi