On Tue, 15 Jan 2013, Tejun Heo wrote: > Hello, Arjan. > > On Tue, Jan 15, 2013 at 04:25:54PM -0800, Arjan van de Ven wrote: > > async fundamentally had the concept of a monotonic increasing number, > > and that you could always wait for "everyone before me". > > then people (like me) wanted exceptions to what "everyone" means ;-( > > I'm ok with going back to a single space and simplify the world. > > If we want (or need) finer grained operation, we'll probably have to > head the other direction, so that we can definitively tell that an > async operation belongs to domains system, module load A and B, so > that each waiter knows what to wait for. > > The current domain implementation is somewhere inbetween. It's not > completely simplistic system and at the same time not developed enough > to do properly stacked flushing. I like your idea of chronological synchronization: Insist that anybody who wants to flush async jobs must get a cookie, and then only allow them to wait for async jobs started after the cookie was issued. I don't know if this is possible with the current implementation. It would require changing every call to async_synchronize_*(), and in a nontrivial way. But it might provide a proper solution to all these problems. Can you think of any reasons why it wouldn't work in principle? It would prevent code from doing "wait until all currently-running async jobs have finished" -- but arguably, nobody should be allowed to do that anyway. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
