Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributed Objects pitfalls and strategies

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.

References: 
 >Distributed Objects pitfalls and strategies (From: John Scalo <email@hidden>)
 >Re: Distributed Objects pitfalls and strategies (From: Aurélien Hugelé <email@hidden>)
 >Re: Distributed Objects pitfalls and strategies (From: Aurélien Hugelé <email@hidden>)
 >Re: Distributed Objects pitfalls and strategies (From: Aurélien Hugelé <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.