Hi Nick,
It sounds like this would be relatively easy to bundle up as a test
app. If you can do so and post it somewhere, I'll think you'll have a
better chance of a helpful response.
Also, are you aware of -[NSObject
performSelector:onThread:withObject:] and friends?
> Assumption #1 - as the threads are both running "currentRunLoop" then I'm
> assuming that each thread has it's own RunLoop instance?
That's correct.
"
+ (NSRunLoop *)currentRunLoop
Return Value
The NSRunLoop object for the current thread.
Discussion
If a run loop does not yet exist for the thread, one is created and returned.
"
-Ken
On Tue, Jul 15, 2008 at 2:45 PM, Nick Kitchener
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a problem with inter-thread communications with
> NSMachPort/NSPortMessage - it works one way after initially working both
> ways..
>
> The application has a main parent thread that spawns a child thread. The
> child thread runs inside an object instance.
>
> The parent passes it's NSMachPort instance through the NSThread
> detachNewSelector to the child. The parent runs a loop and drives it's
> RunLoop.
>
> The child once spawned creates it's own NSMachPort instance and then
> packages it up and sends it to the parent (which the parent receives
> correctly). This is the classic Apple documented 'checkin'. It then enters
> the classic while(1) { RunLoop ... } to drive the runloop.
>
> Assumption #1 - as the threads are both running "currentRunLoop" then I'm
> assuming that each thread has it's own RunLoop instance? I understand that
> the RunLoop is thread unsafe.
>
> The parent can issue as many messages as it likes to the child process. Each
> message gets to the child thread without a problem - each and every time.
>
> Now comes the interesting bit.
> The child uses a single method for all it's send calls back to the parent
> thread - even the checkin uses it - where it calls [NSPortMessage
> sendMessage: ...]. The observed results are that the initial checkin message
> gets to the parent handlePortMessage: whereas subsequent calls don't show
> any errors but the message does not arrive at handlePortMessage on the
> parent. They just vanish. The child and parent threads continue as if
> nothing has happened. The parent can still issue messages to the child..
>
> I've checked with gdb and the ports are correct at each call. I notice
> there's three threads (the thread that's not mine shows as a posix thread
> that runs __CFSocketManager and just sits at select$DARWIN_EXTSN). This may
> be handling the streams that my child thread manages (I assume).
> Activity monitor sample shows the parent 100% in it's loop. The child 100%
> sat at mach_msg_trap which I see from the Apple opensource is the
> send/receive for messages in the mach kernel.
>
> Has anyone had this occur before? Is it a dead/live lock in the OS due to
> threads using each others ports or is it there's no messages being sent?
>
> I'm a complete beginner to OSX/Cocoa but not threading.
>
> Cheers,
> Nick.
> _______________________________________________
>
> 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/kenferry%40gmail.com
>
> This email sent to [EMAIL PROTECTED]
>
_______________________________________________
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]
