> > I'm sure you can figure several of them out if you think about it for a > > few minutes. (Hint: if you have a spinlock that protects access to > > a pointer outside the completion handler, and that pointer is nulled > > when its data is freed, what else might you need to do??) > > Using a spinlock is possible but hard.
Well, spinlocks aren't intended for Aunt Tillie, and they're a rather basic tool ... "using pointers is possible but hard". This is slightly less exagerrated than what you first said: > > > You _cannot_ even in principle synchronize between a completion > > > handler and process context. It's a one way street of communication. > a) you must unlink asynchronously Again (!) you haven't thought this through -- or are trolling. > b) you must be very careful in the completion handler not to > take the lock if you are killed. And how would a completion handler get killed short of Oopsing? > c) the HCD may need to defer the cancelation because > it cannot reliably prevent the hardware from executing the > transfer. But the HCD _does_ do that, and the driver developer doesn't need to worry about anything beyond making sure it doesn't keep pointers around once they've been freed. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
