On Jul 26, 2007, at 7:47 AM, devmaillists wrote:
I think here is a common problem when porting a thread based driver to an IOWorkloop based one.
If an IOCommandAction or an other IOEventSource has to wait for some work to be done by another IOEventSource,
how can this IOEventSource "sleep" , "wait" and let the IOWorkloop go on looping?
Or is there an other conceptional solution to this?
Typically, the solution is "don't try to port drivers from environments with different programming models".
Instead, you should use the other driver as reference material, and write an I/O Kit driver.
In your specific case, you may in fact be confused a little by the frequent use of "workloop thread". IOCommandAction handlers hold the workloop lock, but typically when invoked with IOCommandGate::runAction() they are run on the calling thread. In this case, you can use IOCommandGate::commandSleep() and ::commandWake() to suspend execution and allow other threads to obtain the workloop lock. You should exercise some care here; typically you will need some other way to gate access to the top side of your driver, since whilst sleeping another IOCommandAction can be invoked...
It is generally a bad idea to have IOEventSource::action() handlers sleep waiting for other code that requires the workloop, as you can run into subtle deadlock/starvation issues, and the event source remains disabled while the thread is asleep. If you can describe the driver you're working on in a little more detail, we might be able to point to something similar you can crib from, or offer you more detailed suggestions.
= Mike