Re: New ProjectCenter Icons

[Richard Frith-Macdonald]

On 14 Sep 2007, at 09:47, Dr. H. Nikolaus Schaller wrote:

> Am 14.09.2007 um 10:16 schrieb Richard Frith-Macdonald:
>
> > Actually that's not the case any more than within a monolithic  
> > app.  Methods can fail whether via DO or not, and the code has to  
> > handle such error conditions whether via DO or not.  In fact the  
> > error handling situations are the same whether you are using DO or  
> > not (NSException and checking return values from methods).
>
> No, there is an additonal task of responding reasonably to a  
> timeout situation. And to take care of avoiding deadlocks.

1. You have to respond reasonably to a timeout when communicating  
between modules in a single app (unless you are assuming that a  
problem in one module means the whole app has to hang/die).   DO  
makes that easier because it has builtin timeouts and will simply  
raise an exception that you can handle ... if you are using standard  
method calls to communicate between modules then you need to  
implement your own mechanism.  The default DO timeout is practically  
infinite (making it behave like a normal method call) but you can set  
whatever you like if you think you might need a timeout.

2. Not sure what you mean about deadlocks ... I'm not aware of any  
issue with deadlocks in a DO based system that would not equally  
apply to a similar system without DO.  Typically deadlock occurs when  
app1 makes a DO call to app2 and app2 calls back to app1 and app1  
can't respond until it has the result from app2.  Exactly the same  
situation occurs just as easily between modules in a single  
application.   With DO you can set a timeout, so that instead of  
getting a permanent deadlock you get a delay and an  
NSPortTimeoutException.   Without DO you are stuck with a deadlock  
unless you have multiple thteads and use one to break deadlocks.

> I have several times had the issue that Xcode did hang which made  
> IB hang as well. So I was not even able to save the IB file locally  
> any more. So I had to kill both processes loosing both changes.
>
> Well, you can argue that it the monolithic case you would loose  
> both as well.

Of course.

> But the reason that Xocde did hang *could* have been induced by DO  
> as well (e.g. a deadlock in the DO communication).

Unless you are saying that the DO mechanism itsself deadlocks  
internally (something I've never seen) you are talking about some  
other form of deadlock which has nothing to do with DO and could  
occur between modules in an app that didn't use DO.  My guess is that  
XCode/IB use the default (infinite) timeout for any communication  
between them, and that this makes the DO calls equivalent to normal  
method calls, so you have exactly the sort of deadlock situation you  
would get in a monolithic application.

If deadlocks are a real worry, I'd use notifications rather than  
method calls to decouple modules as much as possible.  Similarly, in  
a multi-app system I'd use distributed notifications rather than DO  
calls.