Nate Lawson wrote: > 1. Run a task at some point in the future but "soon" > 2. Queue a task to be run, definitely after boot is complete > > Notifies are in the first class. Initialization functions for the > various drivers are in the second. ACPI-CA is moving to making all > Notifies completely synchronous (i.e. they wait for the thread to run). Note that I've encountered an issue with synchronous Notify in the Solaris port of ACPI CA on a particular machine. Specifically, the Acer Ferrari 3400 deadlocks while delivering AC/battery events, since Notify() is performed while holding a mutex. The AC/battery driver notify handler evaluates _STA and _BST, and either of these attempt to hold the same mutex. Bob Moore and I have been discussing solutions for this but have nothing firm at this point. While I suppose I *could* make the AC/battery driver Notify handler behave like a high-level interrupt and simply schedule yet another thread to run to handle the Notify, this scheme generally ends up the same as asynchronous Notify in the first place. DanaReceived on Wed Oct 03 2007 - 14:42:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC