On Mon, Mar 17, 2014 at 7:40 AM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote: >> There's already behavior that is somewhat like that with the current >> implementation. If there's an item on a workqueue, it could run at any >> time. From the perspective of the driver/etc. that is using the >> workqueue, there should be no difference between work being on the >> workqueue and the kernel triggering a schedule right after the work is >> removed from the workqueue, but before the work function has done >> anything. > > It is different. mod_delayed_work() *guarantees* that the target work > item will become pending for execution at least after the specified > time has passed. What you're suggesting removes any semantically > consistent meaning of the API. > It will still be at least be pending after the specified time has passed. I'm proposing that we still set the timer. The difference is that there is a possibility the work will already be pending when the timer goes off. There will still at least be an execution after the given time has past. We could still remove the work in the workqueue from the timer function, but this would make the mod_delayed_work not race with any work that was scheduled for immediate execution previously. If you make the timer function remove any pending work from the workqueue when the timer goes off, this is still following the API. The work will still become pending at least after the specified time has passed. >> So to reiterate, calling mod_delayed_work on something that is already >> in the workqueue has two behaviors. One, the work is dispatched before >> mod_delayed_work can remove it from the workqueue. Two, >> mod_delayed_work removes it from the workqueue and sets the timer (or >> not in the case of 0). The behavior of the proposed change should be >> no different than the first behavior. > > No, mod_delayed_work() does *one* thing - the work item is queued for > the specified delay no matter the current state of the work item. It > is *guaranteed* that the work item will go pending after the specified > time. That is the sole meaning of the API. > >> This should not introduce new behavior from the perspective of the >> code using delayed_work. It is true that there is a larger window of >> time between when you call mod_delayed_work and when an already queued >> work item will run, but I don't believe that matters. > > You're completely misunderstanding the API. Plesae re-read it and > understand what it does first. > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
