Re: Getting disk mount notification with Foundation tools
Re: Getting disk mount notification with Foundation tools
- Subject: Re: Getting disk mount notification with Foundation tools
- From: Mike Vannorsdel <email@hidden>
- Date: Sun, 09 Jun 2002 15:54:02 -0600
Through my experiences with multithreading and notifications, these are my
findings:
Notifications generated outside of the application, such as those from
NSWorkspace and NSDistributedNotificationCenter, are posted in the main
thread's run loop.
Local notifications are posted in the run loop of the thread which posted
the notification.
This makes sense, at least for how the notifications are setup on Mac OS X
right now. It would be nice to be able to specify to what thread a
notification goes, or at least have notifications posted to the run loop
where the observer was added.
I've known this for a long time, but had a memory laps in my recent project
and didn't remember these facts until you mentioned needing an NSRunLoop.
Changing my daemon is not a big deal; I just need to swap the threads
around. Like you said, AppKit applications don't usually hit this problem
as the main run loop needs to run for the UI to function (among other
duties). In Foundation tools, you're not so concerned about leaving the
main loop "open".
On 6/9/02 3:23 PM, "Bill Bumgarner" <email@hidden> wrote:
>
That sounds like a potential feature request to be filed to
>
bugreport.apple.com.
>
>
Let me clarify something before more confusion is generated: There doesn'
>
t need to be a running run loop to post or receive notifications
>
[NSNotification]. A notification is delivered immediately.
>
>
However, there does need to be a running run loop to handle distributed
>
notifications and to handle messages received via an NSConnection. In
>
effect, a distributed notification is actually just a standard
>
notification that is triggered by an event-- likely an NSConnection
>
message-- that requires a running NSRunLoop to be posted in the first
>
place. That is, the mechanism that receives the workspace event and
>
generates the notification requires a run loop to receive the message from
>
the workspace itself.
>
>
So, it sounds like the workspace receives the remote message that a volume
>
was mounted/unmounted in the main runloop / thread and posts the
>
notification there because notifications are not thread specific.
>
>
In the context of both command line tools and Cocoa based applications,
>
one needs to allow the main thread's NSRunLoop to run. If you need a main
>
thread that waits on device I/O, does work, or otherwise sleeps [to use
>
Mike's example], then that thread should be separate from the main
>
thread-- it should be a worker thread.
>
>
The alternative is to periodically poll the runloop in your main thread.
>
NSRunLoop provides API to process one event at a time -- if you invoke
>
-runMode:beforeDate: with [NSDate date] as the date, it will process
>
exactly one event before returning YES.
>
>
In Mike's case, he can likely [maybe not-- I don't pretend to have a clue
>
what his code does outside of this and the previous post :-) ] replace the
>
call to sleep() (or equivalent) to a call to NSRunLoop's runBeforeDate:,
>
then use -runMode:beforeDate: to periodically process pending events in
>
his main thread.
>
>
The feature request: Either document explicitly exactly which thread
>
various notifications arrive in or add functionality where the thread
>
within which an observer of-- direct or indirect-- remote notifications is
>
added is the thread within which the notification is received.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.