🚀 go-pugleaf

In article <313CA521.13D8@mediamatic.nl>,
Pascal Haakmat  <pascal@mediamatic.nl> wrote:
>Gregory L Hansen wrote:
>
>> Well... if the Blue Box crashes and is restarted, chances are the program
>> will receive a restart Blue Box event.
>
>Then the blue box would have to restart all the applications that were running at the 
>time the blue box crashed. While I certainly consider this a feasible sort of thing, 
>re-loading every application sure does kill the prospect of 'shorter startup times'.

It's really impossible to say until we get some more information about 
this.  But I will make one assumption; if the Blue Box crashes and is 
restarted, the program will be told about it.  That's all it will take, a 
NewBlueBox event.  All of your data will be in protected threads.  All of 
your window data should be in data structures inside protected threads.  
And you should have some kind of status flag, to keep track of what 
your program is doing, in a protected thread.  If you have that, 
redrawing the interface is almost trivial.  Check your status flag and 
draw the appropriate menus, 
with the appropriate items highlighted or dimmed.  Cycle through your 
windows list creating every window in the proper location and the 
proper size (stored in your window records), the document in the proper 
position (call your window update routine), any controls highlighted or 
dimmed as appropriate (in your control records).  Kind of like when you 
open your word processing document and the window and document are the 
same as when you left them?  This is *exactly* the same thing!  Your 
program already does that, so just call your routine again.  
     As far as I can see, it will be almost exactly like writing portable 
code, since you have to isolate the user interface anyway.  And you will 
not have to reload anything.  That's the whole point of the Blue Box; 
when it crashes, your threads don't disappear and they don't have to be 
restarted.  I'm sure it will be a little extra work.  But it's still 
going to be only a little, not a lot.

That's all I can say about it until we get some more info.  But all I 
need is that RestartBlueBox event and I'm set.

>Hmmm. The program must check upon startup whether it has crashed and re-collect at 
>least some system state from various assorted places. I do not consider this a 
>trivial matter.

As I said, I'm thinking the program won't restart.  The program will 
recognize the restart, then redraw everything.  And your system state 
should already be stored away.  How else are you going to update windows, 
scroll through your documents, that sort of thing?  You have to keep 
track of everything.  Doing all of this isn't exactly trivial.  But 
programming for Copland should be trivial since you have it whether you 
use Copland or not.

>Which makes me think about where the spawned threads are going to 
>store their results (in their own part of protected memory?) and how 'the UI engine' 
>is going to retrieve it. This would require some PPC toolbox mechanism I suppose?

I have a different interpretation.  The UI doesn't retrieve anything.  
Control is never given to the UI.  When the program wants to change 
something on the screen, it tells the UI to change it.  When the program 
wants some data, it tells the UI to grab it.  But if the UI doesn't 
exist, the program could go on oblivious to its absence (except that it 
will keep waiting for that data).  This is different from, for instance, 
storing a data pointer in the refCon fields of your WindowRecords, then 
using the windows to get to the data.  In short, don't.  Set up your own 
data structures, and get to your windows through the structures.  If you 
do it the previous way, when you lose your window, you lose the 
pointer to your data.  If you do it the latter way, when you lose your 
window, you still have your data and you can redraw the window and stick 
the handle for the new window in the field where the old one was.

>The 
>whole concept of 1 single program having to set up all sorts of communication 
>channels with other parts of ITSELF just does not appeal to me at all. It sounds like 
>consulting yourself on whether you want ice-cream or not.

I have no idea how that's going to work.  I've talked to people about 
keeping maultiple things happening in a program.  My method is to use a 
linked list of data structures, each having a field that will identify the 
operation 
you're doing on it.  Then you can cycle through the list doing one or a 
few iterations on each one at a time.  If you need two processes to talk 
to each other, like one draws a shape and another calculates properties 
of it, you could run through the list until you find the calculate 
function then exchange pointers.  I've been told this is the perfect 
job for the Thread Manager, which apparantly allows PMT within a program 
(but not between seperate apps).  But I have no idea how they communicate.

Sometimes I like thinking through this kind of thing.  But until I'm 
actually pounding away at it on the keyboard, it's all speculation.