NSConnection; serving a class in-process / crossing thread boundary
NSConnection; serving a class in-process / crossing thread boundary
- Subject: NSConnection; serving a class in-process / crossing thread boundary
- From: email@hidden
- Date: Mon, 20 Mar 2006 12:42:19 +0100
- Thread-topic: NSConnection; serving a class in-process / crossing thread boundary
Hi All
I have a class, lets call it SlowMounter - that performs long operations
(er, like, mounting a network disk!) - and as is typical in a GUI app, I
don't want to block the GUI thread while this slow operation is taking
place. So I have placed the long running operation in a thread and
connected it via an NSConnection to the GUI - allowing the obvious
benefits:
- no manual cross-thread marshalling when the server makes a delegate
method call into the GUI - clearly the NSConnection/message queues do
all of this for me.
- no special locking required in the SlowMounter class, since it's
running in a separate thread anyway.
My aim:
I'd like to tell the SlowMounter to SHUTDOWN while it's halfway through
mounting a disk on a network.
In the above described model this does not work, because while the
slow-mounter method is running [performing the mount and so on], the
incoming messages from the GUI are simply queued in the NSThread message
queue that is responsible for the SlowMounter / NSConnection.
So the messages from the GUI have to actually *wait* for a prior method
call in the SlowMounter to finish before the SlowMounter's message pump
is able to dispatch the next method call request. This is also no
problem - and makes logical sense to me. So far, so good. Of course I
thought.. I'll just change the SlowMounter to run it's time intensive
operations in another thread... I thought: Great! Client GUI won't even
know the difference, and the world will be a better place!
My problem:
I moved the actual mount: method into a thread within the SlowMounter -
all benefits still retained, i.e. the GUI has *no* idea how this stuff
is implemented, and does not care, and I *still* don't have to play
games trying to ensure that any returned messages from the mounting
process (via a delegate callback) are marshalled onto the right thread
(i.e. the main GUI thread).
My problem is, that as soon as I access properties on an NSDistantObject
that represents a method parameter - for example, the name of the volume
to mount, the runtime throws an exception telling me that something
similar to the following:
'NSDistantObject can't be accessed from another thread'.
So this means, that when I provide a 'service' via the NSConnection
mechanism - even if it's intra-process, I must do *ALL* processing on a
single thread within the so-called 'server'? Yikes!
Can I get around this somehow? I'd like to maintain simplicity in the
GUI, so that in the GUI there's no issues about having to marshall stuff
onto the main GUI thread.
I did try putting 'bycopy' into the method decl, but this didn't help
either.
Any help appreciated.
John Clayton
---------------------------------
UBS AG
Information Technology
Europastrasse 2, Opfikon
Tel. +41-1-239 23 36
#claytojo
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden