Re: New ProjectCenter Icons

[Dr. H. Nikolaus Schaller]

Am 14.09.2007 um 11:21 schrieb 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

How do you handle timeouts in a single-threaded method call?

I think we are on a much too abstract level. Let's take an example:

If you press the Build button in PC you probably want to have the  
latest version of your GORM file saved before building. I.e. PC must  
notify GORM to save all touched files first. And PC has to wait until  
this is done. This action method might timeout because GORM is not  
repsonding for any reason. Then you have to cancel the Build process  
and notify the user.

In a monolithic approach, you would simply call something like  
[gormDocumentController saveAllDocuments:self]. If this returns YES,  
everything is ok. If it returns NO, there was some write error. If it  
hangs - then your kernel did not respond and you can't do anything  
either and the best thing is that your application hangs. Therefore,  
you do not have to care about timeouts in this case. And there is no  
"GORM did time out" warning message to be provided to the user.

> 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.

Two applications have two user interfaces and they run in different  
processes. This raises new issues that do not occur in a monolithic  
application. A user can click something in app1 which triggers a lot  
of activity which ends up after some time in a DO call to app2 making  
it wait for a response.

In the meantime, the user has clicked on app2 which results in a DO  
call to app1 waiting for a response which app1 can't deliver because  
it is waiting for app2's response.

This can not happen in a single-threaded application because all user  
events are synchronized through a single event queue.

>   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

DO implies concurrency in multiple threads or tasks. A monolithic app  
can be single-threaded avoing some issues.

> 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.

It depends on whether the sender needs a response or oneway DO is  
sufficient.

But we are back on the implementation level and I think the basic  
direction should come from a users's perspective. If they want to see  
multiple applications or a single, central one.

Any daily GORM/PC users out there to comment?