Re: NSConnection - is this expected behavior?
Re: NSConnection - is this expected behavior?
- Subject: Re: NSConnection - is this expected behavior?
- From: Neil Clayton <email@hidden>
- Date: Mon, 19 Feb 2007 21:09:11 +1300
OK thanks, that explains some things. Unfortunately, I need to use
the main thread for some QT work, so I guess I'll have to go down the
route of putting the DO onto it's own thread, and using queuing to
pass "messages" around. It just feels a bit messy.
---
Regards,
Neil Clayton
On 19 Feb 2007, at 19:40, James Bucanek wrote:
Neil Clayton wrote on Monday, February 19, 2007:
1) Start server (the example is so trivial, that it has no code to
start the server itself).
2) Start the client. It connects automatically from within
awakeFromNib.
3) Tell the server to "go". It starts performing a long running
operation (20s).
Is this "long running" process in the same thread as the run loop
where you started the DO connection? If so, then that's your problem.
DO is event driven, just like the GUI. You have to let the run loop
run or DO events are not handled. Said another way, until the
message called by the client returns, no new DO events will be
processed.
DO won't make your server calls asynchronous for free. If you want
asynchronous command handling you have to implement it. This is how
I do it:
1) Server opens a port and waits for clients.
2) Client connects.
3) Client calls -go on server. In the same call, the client passes
a "listener" object that the server will use to return status
updates. Server starts process in a separate thread and returns
immediately.
4) Client returns to its run loop and waits for status messages
from the server. Server posts status updates by calling [listener
performOnMainThread:...]. This avoids lots of crazy multi-threading
issues when trying to send DO messages from multiple threads.
5) Server finishes, sends "isDone" message to client, and releases
the listener.
In between these steps, both the client and server's run loops are
running, allowing them to accept other connections, process
messages from other sources, update the GUI, and so on.
If the client disconnects prematurely, attempts to send a message
to the listener will throw an exception. Catch any exceptions
thrown when sending messages to the listener and discard it if the
message fails. The only hitch is that you can't release a dead
listener. 'release' is a message and that will fail too.
--
James Bucanek
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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