Re: Diskarbitration callback
Re: Diskarbitration callback
- Subject: Re: Diskarbitration callback
- From: Kevin Elliott <email@hidden>
- Date: Thu, 8 May 2008 10:44:00 -0700
On May 8, 2008, at 9:58 AM, Andy Green wrote:
Wow - works like a charm!
When I say that, I mean it works, but I have no idea how! I'll have to
go read up on run loops: in the meantime here's the working code for
posterity - is this what you meant?
And an awkward question: my 'real' code will be in a library, called
from both command line tools, and from a cocoa app. Is this run-loop
hocus pocus safe in both environments?
Basically it depends on how you expect your code to be used.
A RunLoop is basically a generic construct for waiting on callbacks.
They're created on demand (whenever you call and RunLoop function),
and map to threads so each thread has one runloop, unless the thread
doesn't make any runloop related calls.
I don't have your code in front of me, but I've I'm understanding the
flow of emails, I can make a few comments.
The core problem with your original code was that you were firing off
a number of events (DADiskUnmount, DADiskEject), then calling
CFRunLoopRun, then wondering why your callback never fired. Your call
back never fired because nothing happened- the unmount/eject
completed before you were waiting in your runloop.
The code Axel sents works because he's looping against the runloop
which means he's back waiting in it before the eject call get to
diskarbitrationd starts processing your event. As a mental "image"
it's worth thinking of the "DADiskEject/DADiskUnmount" as basically
sending a message to diskarbitrationd which will respond to that
message in the future.
I believe the custom run mode that Axel is using-
CFSTR("drvHostBaseDA") is unnecessary. His code should work just as
well with kCFRunLoopDefaultMode.
Now, to using it in a library, it depends on what your trying to to.
If your trying to create a disk arb wrapper, my suggestion would be to
create your own thread, file your callbacks against that threads
runloop, and then have your API provide hooks to modify what ever
behavior you need to modify (with appropriate locks, etc.). If your
trying to do something else, well, I'd need to know more about what
your trying to do.
I will say that calling CFRunLoopRun or any of it's similar ilk is
almost certainly a bad idea unless your in your own thread. Certainly
for GUI apps it's VERY unusual for a run loop to be run directly and
will probably result in all sorts of oddities. It's not against the
"rules", but it's something you'd need to be very careful about doing-
GUI apps generally have lots of things hooked up to the run loop and
your running it directly is either going to cause unexpected pauses as
other events are delayed, or possibly reentry problems depending on
what exactly you do.
I'd encourage you to explain more about what exactly your trying to do
before you continue...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden