site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com 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. On May 8, 2008, at 9:58 AM, Andy Green wrote: 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com