On Mar 1, 2008, at 8:35 PM, Kyle Sluder wrote:
On Sat, Mar 1, 2008 at 9:01 PM, Adam R. Maxwell <[EMAIL PROTECTED]>
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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]