Re: Distributed Objects pitfalls and strategies
Re: Distributed Objects pitfalls and strategies
- Subject: Re: Distributed Objects pitfalls and strategies
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 31 Mar 2004 22:24:45 +1000
The advantage with letting the run loop code handle it is that it can
be updated to whatever threading/process/etc model Apple feel like
using, making optimum use of it. E.g. it may not poll, but rather
use interrupts of some sort (taking wild guesses here, but you get
the idea). Plus, it generally makes your code shorter. :)
you are right, but i'm pretty sure apple does not optimize it at all,
re reading the Chris Kane messages on this list make me think that the
run call is just polling... but i'm maybe wrong!
You're probably right. Still, I'm an idealist. :)
for the moment, polling the run loop every second consumes virtually
no CPU at all (mesured on my test project with top).
In fact i think the main problem with the 1 second polling is when the
client messages the server (which has just polled the run loop) must
wait 1 second before the server repoll the runLoop and see it has been
messaged... 1 second is a HUGE delay when dealing with networks (in
particular LAN !) so this slow the connection for nothing... thus, i
recognize that it is not beautifully designed ;)
No, there isn't a 1 second delay. What you're doing when polling the
runloop is saying "run for at most 1 second, then return". So a whole
series of messages may go back and forth on the run loop during that 1
second. Then you get processing time again (the run.. method returns)
- you check your flags, do whatever, then run it again [for up to
another second]. There are no significant latency or performance
issues with your design, other than the use of polling, which as you
have measured has no significant performance impact.
So, if you don't really need your app to be able to shutdown within 1
second, increase the time interval you run the loop for. E.g. for a
server intended to run indefinitely (days, weeks, months) you could
easily get away with 60 seconds, maybe more. For an end-user system, 1
second is probably about right... I guess as a user I wouldn't
mind/notice too much if an app took an extra 5-10 seconds to quit, but
I'd like to think it won't if it can help it. :)
i'm really interested in knowing how do you control the input sources
of the runLoop... how do you achieve to be *sure* there is only YOUR
connection(s) as input source(s)...
I don't know... it's just never been a problem. In some situations I
can ignore the issue by ensuring the only time I need to shut down my
connection is when my app quits, in which case run returns
automatically. In situations where I do tear down the server
connection, I normally find that explicitly invalidating each DO object
(NSConnection's, ports, proxies, etc) does the trick. Sometimes it's a
nightmare, but usually a nice hierarchy forms naturally - i.e. calling
invalidate on NSConnection invalides it's port(s) [from memory].
I don't have any particularly good examples of this on hand - I haven't
had time to work on any DO projects recently, so everything's stagnant
and "in pieces", so to speak.
great, at the time i coded this, i did not think about this, but
writing my previous message i suddendly thought about the client
passing "self" to register itself... thanks to have confirmed this !
your code is indeed much more simpler and cleaner !!
I've said it before, and I'll say it again, just to annoy the Apple
guys - ;) - DO should be updated to be P2P-orientated, not
client-server.
this open *very* wide areas to DO imho :D
i can think of several levels of data sharing : in a company, only a
limited group of people can access the full data when the clients can
only access a small part of the shared infos etc...
this is fantastic and give me many ideas for our current project !
Glad to hear it. Just remember to reign in your excitement as
appropriate when implementing the system - SecureSocketPort is
ultimately just a meaty wrapper over SecureTransport; it's not going to
solve the world's problems and cure cancer for you. :)
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.