Re: NSMachPort thread safety
Re: NSMachPort thread safety
- Subject: Re: NSMachPort thread safety
- From: "Adam R. Maxwell" <email@hidden>
- Date: Sat, 1 Mar 2008 20:52:04 -0800
On Mar 1, 2008, at 8:35 PM, Kyle Sluder wrote:
On Sat, Mar 1, 2008 at 9:01 PM, Adam R. Maxwell <email@hidden>
wrote:
Thanks, but I think you're misinterpreting the example :). The
object
has a single NSMachPort ivar, added to the some thread's runloop.
When a notification arrives on a different thread in
processNotification:, it messages the NSMachPort. When the port's
delegate receives handleMachMessage: it processes the notification
since it's guaranteed to be on the correct thread.
Okay, so I don't understand where the problem is. The reason for the
locking and thread-checking is so that two threads can share the
non-thread-safe NSPort object. Unless when I said "messages" you were
thinking in Mach port terms; I meant you can't send an Objective-C
message from thread A to a non-thread-safe object on thread B (unless,
of course, you implement the locking yourself).
Yes, and there's no lock around the call to sendBeforeDate:. Hence my
question: is the example flawed, or is NSMachPort thread safe? To
make things more interesting, NSMachPort appears to be implemented on
top of CFMachPort, which is thread safe according to the docs...but
the NS layer sometimes removes thread safety (as in NSRunLoop vs.
CFRunLoop). I reimplemented one class with a CFRunLoopSource and a
raw mach port, but using NSMachPort is easier.
--
adam
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden