Re: CFRunLoopStop too powerful when invoked by bootstrap per-user daemon?
Re: CFRunLoopStop too powerful when invoked by bootstrap per-user daemon?
- Subject: Re: CFRunLoopStop too powerful when invoked by bootstrap per-user daemon?
- From: Pete Gontier <email@hidden>
- Date: Fri, 02 Nov 2007 12:22:21 -0700
- Thread-topic: CFRunLoopStop too powerful when invoked by bootstrap per-user daemon?
Title: Re: CFRunLoopStop too powerful when invoked by bootstrap per-user daemon?
This turned out to be our bug. The library was calling CFRunLoopStop in a matching notification function, which ran once before the library started its activation of the run loop. This stopped an activation which had not yet been created. In the case of the single-threaded daemon, CFRunLoopStop stopped the caller’s activation, and in the case of the multi-threaded Cocoa app, CFRunLoopStop stopped a non-existent activation, which had no effect. I wonder if there is a debugging version of CFRunLoopStop wich might have warned us that we’d tried to stop an activation which did not exist.
— Pete Gontier <http://www.m-audio.com/>
From: Pete Gontier <email@hidden>
Date: Fri, 02 Nov 2007 10:03:31 -0700
To: <email@hidden>
Cc: Cobey Gatos <email@hidden>
Conversation: CFRunLoopStop too powerful when invoked by bootstrap per-user daemon?
Subject: Re: CFRunLoopStop too powerful when invoked by bootstrap per-user daemon?
I should have included some additional information in my first post. Rather than attach it to either end of the original, I’ve re-composed the complete message.
CFRunLoopStop is documented as stopping the “innermost activation” of the given run loop. In a regular application, this seems to be the case. However, in a bootstrap per-user daemon, CFRunLoopStop seems to stop all activations of the run loop.
The “regular application” is a Cocoa app which calls NSApplicationMain on the main thread and later spawns another thread on which it calls our library which in turn calls CFRunLoopRunInMode and CFRunLoopStop. Since every thread gets its own run loop, it makes sense that this call to CFRunLoopStop would have no influence on the Cocoa run loop, which is on the main thread.
The bootstrap per-user daemon has only one thread, on which it calls CFRunLoopRun and then the aforementioned library, which in turn calls CFRunLoopRunInMode and CFRunLoopStop. This call to CFRunLoopStop stops both the call to CFRunLoopRunInMode (as expected) and CFRunLoopRun (not expected). But here’s where it gets weird.
The unexpected behavior only occurs during startup, i.e. if we launch the progress as a regular user, it works as expected, but if we install the app where it will be for the customer and let the system launch it at startup, the call to CFRunLoopStop will have the unexpected behavior.
Has anybody else encountered this? Is there a downside to simply invoking the outer run loop again if/when it exits before we wanted?
— Pete Gontier <http://www.m-audio.com/>
_______________________________________________
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