On Mon, Jul 26, 2010 at 08:51:50PM +0200, Tejun Heo wrote: > Hello, > > On 07/26/2010 06:31 PM, Michael S. Tsirkin wrote: > >> On 07/26/2010 06:05 PM, Tejun Heo wrote: > >>> * Placing try_to_freeze() could be a bit annoying. It shouldn't be > >>> executed when there's a work to flush. > > > > BTW why is this important? > > We could always get another work and flush right after > > try_to_freeze, and then flush would block for a long time. > > > > BTW the vhost patch you sent does not do this at all. > > I am guessing it is because our thread is not freezable? > > Yeap, I think so. > > >> * Similar issue exists for kthread_stop(). The kthread shouldn't exit > >> while there's a work to flush (please note that kthread_worker > >> interface allows detaching / attaching worker kthread during > >> operation, so it should remain in consistent state with regard to > >> flushing). > > > > Not sure I agree here. Users must synchronise flush and stop calls. > > Otherwise a work might get queued after stop is called, and > > you won't be able to flush it. > > For freeze, it probably is okay but for stop, I think it's better to > keep the semantics straight forward. What are the semantics then? What do we want stop followed by queue and flush to do? > It may be okay to do otherwise > but having such oddity in generic interface is nasty and may lead to > surprises which can be pretty difficult to track down later on. It's > just a bit more of annoyance while writing the generic code, so... > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
