It's exciting to see stuff like the ThreadsLib already being brought on
line. Building CGI's if FB^3 is going to make a lot of twidders twitch!

I was looking over what you have done, and tho it is not really my field,
it seems that some of your LONGs might need to be @LONG. C's use of "&" is
an exact duplicate of FB's "@". It means "pass the address of a variable."
C uses "*" to mean "use a variable that is somewhere else." The technical
translation in FB^3 is to use @vPtr& and then refer to it inside of a local
fn with vPtr&.nil&. If I had to guess at a mistake, I'd say that in one or
more cases the toolbox call for NewThread is expecting @LONG instead of
LONG. Dunno...


>This may be one for Andy to take a look at.
>
>I'm working on getting threading to work in FB^3 for my Threaded ACGI
>Framework, and I think I'm close but I've hit a "guts of the machine"
>snag. Here's the relevant part of my Tlbx Threads.INCL, the way I
>think the TOOLBOX calls should look in FB^3. I'm pretty sure I have
>the LONG's and WORD's right (see pascal header code below), and I'm
>sure the library PPC code is getting called. (I'm only concerned with
>compiling PPC code right now, but I think the assembly codes are
>right, too.)
>
>-------------
>LIBRARY "ThreadsLib"
>TOOLBOX FN NewThread(LONG, LONG, LONG, LONG, LONG, LONG , @LONG) =
>WORD `0x303C,0x0E03,0xABF2
>TOOLBOX FN DisposeThread(LONG, LONG, WORD) = WORD `0x303C,0x0504,0xABF2
>TOOLBOX FN YieldToAnyThread = WORD `0x42A7,0x303C,0x0205,0xABF2
>LIBRARY
>-------------
>Here are the pascal headers:
>
>FUNCTION NewThread(threadStyle: ThreadStyle; threadEntry:
>ThreadEntryProcPtr; threadParam: LONGINT; stackSize: Size; options:
>ThreadOptions; threadResult: LongIntPtr; VAR threadMade:
>ThreadID):OSErr;
>     INLINE $303C,$0E03,$ABF2;
>
>FUNCTION DisposeThread(threadToDump: ThreadID; threadResult: LONGINT;
>recycleThread: BOOLEAN):OSErr;
>     INLINE $303C,$0504,$ABF2;
>
>FUNCTION YieldToAnyThread:OSErr;
>     INLINE $42A7,$303C,$0205,$ABF2;
>--------------------
>My main program sets up a new thread, which is handed a procptr
>(procptr& = PROC "THREADHANDLERENTRY") in the second parameter. Then
>the main program calls YieldToAnyThread, at which time the OS Thread
>Manager transfer control to the thread handler entry proc ptr, which
>is at an ENTERPROC. This calls my ThreadHandler function, which does
>its thing and eventually disposes of the thread. Here's what's at
>THREADHANDLERENTRY:
>
>--------------------
>"THREADHANDLERENTRY"
>ENTERPROC FN ThreadHandlerEntry (myThreadData&)
>FN ThreadHandler(myThreadData&)'ThreadHandler is prototyped above
>EXITPROC
>--------------------
>(in FBII I had:
>"ThreadHandlerEntry"
>ENTERPROC (gThreadParam&)
>   GOSUB "THandler"
>EXITPROC and it worked magnificently.)
>--------------------
>
>The call to NewThread comes back with no error so that's ok. I
>dropped into macsbug just before YieldToAnyThread and by the looks,
>the thread manager is swapping registers for the new thread just like
>it should, so I'm reasonably sure the new thread is there waiting for
>activation. But I'm getting a consistent "PowerPC Access exception at
>AAFE0700" after YieldToAnyThread. When I disassemble the code at
>THREADHANDLERENTRY, the first opcode is a "b" with a FCOD
>...FB^3.PPC'... to the right, and the second opcode is "lha
>r23,0x0700(r30) | AAFE0700". That last number catches my attention
>because it's the same address that keeps coming up in the PPC
>exception. However at that point my ignorance of PPC assembler stops
>me cold. Any idea what I may be doing wrong? Thanks for your help.
>
>
>--Steve
>
>_____________________________
>Steven J. Stratford, InterNetyx.com
>Supercharge your website!
>www.internetyx.com
>920-206-9197
>_____________________________
>
>--
>To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>




Best,

-STAZ  ~)~

800.348.2623 Orders  http://www.stazsoftware.com
228.255.7086 FAX     mailto:staz@...