[futurebasic] Re: [FB] FB^3 Threading Puzzle

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : September 1999 : Group Archive : Group : All Groups

From: Robert Purves <robert.purves@...>
Date: Tue, 28 Sep 1999 21:59:32 +1200
>>The light is dawning!!! Is the ProcPtr always at a fixed offset from
>>the UPP? If so I should be able to pass the UPP plus that offset to
>>the ThreadManager instead of the UPP.

This sounds dangerously wrong to me.

>I tried handing threadmanager the procptr instead of the UPP address
>but it didn't work. Looking closer, the procptr appears to point to
>an address containing a memory address, and if I hand _that_ to the
>threadmanager it's still no go.

False dawn, obviously. Do I gather that the offending Universal Procedure
Pointer is one that has been created by FB^3, courtesy of UNIVERSALPROC?
And further, is the purpose of this to provide a call-back from the Thread
Manager, so that (when it feels so minded) it can ask part of your program
to do something?

The need for a UPP arises because (a) the Thread Manager may be either
native or 68K, depending on the MacOS version (when I last looked it was
still 68K), and (b) the Thread Manager does not know whether your program
is native or 68K. The job of the UPP is to allow calls in any of the 4
"directions" to work automatically (68K->PPC and vice versa, 68K->68K,
PPC->PPC). The MixedMode manager does this by inspecting the UPP data and
doing a mode switch only if required.

Do you want to post the MacsBug "drd" view of the UPP and its ProcInfo, for
public scrutiny? If the UPP is wrong, then the crash is explained at once.

Lastly, I assume that you know the MacsBug command scream, which displays a
bunch of (to me) incomprehensible rubbish about current threads, but which
for you would be as the music of the crystalline spheres...

Robert