On Thu, 17 May 2007, Hans Petter Selasky wrote: > > In Linux, the USB callbacks are generally atomic. Does that answer > > your question? > > Yes. So you protect the callback with a lock to make it atomic?
No, you don't understand. The callback is atomic because it is not allowed to sleep. That's what "atomic" means. It has nothing to do with locking or protection. > > > b) You don't pre-allocate transfers, resulting in synchronous/blocking > > > calls everywhere, and no-one thinks about what can happen then :-) > > > > Your reasoning is illogical. Why does allocation have to be blocking? > > Memory allocation is blocking in that way it might have to flush out memory > pages to a harddisk, before those pages can be allocated by something in the > kernel. Of course there exists no-wait options that you can pass to "malloc", > but I wouldn't rely too much on those flags You _can_ rely on the "no-wait" option to prevent the allocation from sleeping or flushing pages to a disk... > unless you are allocating from a > pre-defined memory pool, where you know that there is memory reserved for > you. ... and you can't rely on "no-wait" to succeed unless, as you say, you already know there is memory available. But that's also true for early, blocking allocations; there's nothing special about late, non-blocking malloc. With pre-allocation you might fail at the beginning, and with late allocation you might fail in the middle. Either way, you fail. So what's the big deal? Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
