The console message you described in your earlier message happens when diskarb sends you a message and then times out waiting for a response.
So, not to pick nits, but what do we mean by "message" and "response"? Are we talking about the callback routines that I have registered with diskarb? Or are we talking about events on the DASession's run loop?
Currently, my code is designed so that it doesn't register callbacks with diskarb until it begins an action which requires the callback. So, when it performs an action which will result in an IOMedia object becoming available, it calls DARegisterDiskPeekCallback and then spawns a thread to perform the action.
- (void) setActiveZone { DARegisterDiskPeekCallback(daSession, // DASessionRef session, NULL, // CFDictionaryRef match, 0, // CFIndex order diskPeeked, // DADiskPeekCallback callback, self); // void * context
[NSThread detachNewThreadSelector: @selector(doSetActiveZone) toTarget: self withObject: nil]; }
- (void) doSetActiveZone { [userClient setActiveZone: password]; }
When my diskPeeked callback is called, I check to see if the disk that appeared is one that I'm interested in, and then claim the disk. I also unregister the diskPeeked callback. (Perhaps this is the culprit, here?)
- (void) doDiskPeeked: (DADiskRef) inDisk { // NSNoLog(@"-[SAI_Disk doDiskPeeked]\n");
io_service_t theMediaService = DADiskCopyIOMedia(inDisk);
if ([self ownsMediaService: theMediaService]) { // and Grab it for our personal use.
DADiskClaim(inDisk, // DADiskRef disk, kDADiskClaimOptionDefault, // DADiskClaimOptions options, nil, // DADiskClaimReleaseCallback release, nil, // void * releaseContext, diskClaimed, // DADiskClaimCallback callback, self); // void * callbackContext );
// We're no longer interested in approvals.
DAUnregisterCallback(daSession, diskPeeked, self); }
IOObjectRelease(theMediaService); }
Again, Thanks for your time, Ron AldrichSoftware Architects, Inc. On May 22, 2008, at 5:16 PM, Ed Wynne wrote:
On May 22, 2008, at 7:54 PM, Ron Aldrich wrote:
As far as I can tell, I've registered it with the application's main run loop, which should be unblocked, for the most part.
Here's the code that sets up the DASession:
daSession = DASessionCreate(kCFAllocatorDefault); NSParameterAssert(daSession != nil);
daApprovalSession = DAApprovalSessionCreate(kCFAllocatorDefault); NSParameterAssert(daApprovalSession != nil);
daRunLoop = CFRunLoopGetCurrent(); NSParameterAssert(daRunLoop != nil);
DASessionScheduleWithRunLoop(daSession, daRunLoop, kCFRunLoopCommonModes); DAApprovalSessionScheduleWithRunLoop(daApprovalSession, daRunLoop, kCFRunLoopCommonModes);
There is, however, a modal sheet being displayed while all this is going on. Could that be preventing the DASession from processing events?
The usual suspects for handling modal sheets / dialogs all handle it with a common run loop mode, so your code should be doing the right thing to deal with this situation... unless your modal sheet isn't spinning on a common run loop mode. Also, while the call to DARegisterDiskPeekCallback is being made on the main thread, the call to DADiskClaim is not. Could this be a problem?
I wouldn't expect this to matter.
The console message you described in your earlier message happens when diskarb sends you a message and then times out waiting for a response. So the behavioral pattern I described must be happening, it may just be for a secondary reason. DiskArb has a little known, and very annoying, behavior where it will disconnect clients once they have timed out. Are you certain the timeout message is in response to the action you are associating it with? Perhaps some earlier action left your app unresponsive long enough to cause DiskArb to whine and disconnect you. Later actions would then just appear to be deaf.
-Ed
|