> On Mon, 15 Jan 2007, YAMAMOTO Takashi wrote:
> 
> > > 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?
> >
> > i don't think they are issues.
> 
> I think they make it unclean. Maybe there are other opinions..

it doesn't come without costs...

> > > 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".
> 
> how long is too long?

i understand your concern about vagueness here.
but i think we can use a common sense as we currently do for callout handlers.

> > 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.
> 
> True (and creating a workqueue is simple). Are you arguing against an api
> for timed work now?

if it needs to expose workqueues to users.

YAMAMOTO Takashi