On Fri, May 18, 2012 at 11:02:47AM +0100, Alan Cox wrote: > > Well, I can definitely understand your reservations about the code; it's > > strange and foreign and complicated. But having beaten my head against > > the various problems and difficulties inherent in asynchronous > > programming for years - well, having found a way to make it sane to me > > it'd be madness to go back. > > I think its more of a different paradigm than complicated. Yeah, that's probably apt :) > The big > question I'd have to ask is how does it fit with hard real time. That is > a big issue given the gradual merging and getting of "hard" real time > into the kernel proper. > > In some ways it's not that strange either. A look at what happens on some > of our kref handling in drivers is very similar but hardcoded. > > Is the handling of priority inversion within closures a well understood > and solved problem ? Haven't really thought about it (aside from deadlocks which are a slightly different issue). AFAICT there shouldn't be much to worry about, at least with the way I'm using closures today; scheduling is all handled by the existing workqueue code and you have to explicitly say which workqueue a function is going to run out of. There are the wait lists I've implemented but that's mostly just for when some thread/closure is waiting on an arbitrary event to become true - analagous to wait_event(), in which case you want everything on the wait list to to run at once which is all it implements. If the closure wait lists ever did end up being used in a situation where priorities or priority inversion was more of a concern it wouldn't be a huge deal to swap out the implementation for something more sophisticated, or just use the existing wait_queue_t. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
