On Thu, 17 May 2007, Hans Petter Selasky wrote: > If you need to do Async stuff, then you have to do it in a separate thread or > in a so-called task-queue. Else you are in for great trouble! That was the > big "sin" in the old USB stack on FreeBSD: Calling synchronous USB callbacks > from everywhere, like ioctl/read/write - callbacks. > > Is that a problem on Linux also?
It's hard to answer; your use of terminology is peculiar. The word "synchronous" does not mean capable of blocking; it means that the routine waits until a result is received. It is not directly related to whether the routine runs in a process context (which can sleep) vs. an atomic context (one which isn't allowed to sleep). Referring to a callback as "synchronous" doesn't make sense. A callback doesn't send a message -- it _receives_ a message -- and hence it doesn't need to wait for any result. In Linux, the USB callbacks are generally atomic. Does that answer your question? > On Linux I see no locks used in the USB drivers, so they are solely protected > by interrupt-level mechanisms. That's an awfully strange thing to say. No locks used in the USB drivers? Good lord, they are full of locks! Semaphores, mutexes, spinlocks -- you name it, it's in there. > My rule is that: Synchronous or blocking calls _must_ happen in a config > thread that you can wait for. Else asynchronous calls on pre-allocated > transfers can happen anywhere. What distinguishes a "config" thread from any other kind of thread? What distingishes threads you can wait for from threads you can't wait for? What's wrong with a config thread that you can't wait for making a blocking call? Who cares if you can't wait for it? -- the thread will still carry out the call okay. > The problem clearly appears on Linux SMP because: What problem? Or should I say, Which problem? > a) No locks are in the USB drivers (then they must be all so-called "Giant" > locked) You must be living in some sort of fantasy land if you really believe this. Or else you're looking at a version of Linux from 8 years ago. > 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? In code paths which can't block, we do non-blocking late allocation. And we do think about what can happen. 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
