From: | David McMinn |
Date: | 27 Jul 2001 at 11:17:35 |
Subject: | Re: Spawning tasks |
Hi Demon
> function that created a separate task from inside the running program (cant
In Blitz? Hmmmm....
> But, how do I label part of my code(the bit I want as a task) so I can find
> it`s address and pass this location to the function?
Either:
my_new_proc:
; Do stuff here
Return ; Ends new process
Then use ?my_new_proc as the label. Or you could do this:
my_new_proc:
Function.l somecrap{blah.w}
; blah!
Function Return rc
End Function
And then use ?my_new_proc+6 as the label. But you might also need to put
RunErrsOff...RunErrsOn round the function, otherwise the debugger might
have a heart attack (it does when you use this kind of method with hooks).
> Secondly,I read that normally a new task cannot read the global variables
> created by it`s parent,although compilers insert code when requested that
> takes care of this. Since Blitz isnt a C compiler, I take it that it wont do
> this, so does anyone know howto do it?
Well, for a start you'll want to create a new Process, not a Task. Tasks
are not allowed to do any (disk?) IO, so they'd probably be pretty
useless in Blitz (unless you know for sure you want to use a task).
Your main problem will be in the way Blitz programs work. All commands in
Blitz (including the OS commands) expect to have had their libraries
initialised on program startup. When you start a new process this
initialisation does not take place, it just jumps straight to the code,
so it will only work if the new code is using the memory locations for
the main program startup. And because of this you cannot quit your main
program until all your sub-tasks have exited, or they'll be accessing
random gibberish in memory. This might work perfectly well, assuming all
the commands use the original addresses.
To get access to the global variables, you'll need to restore a5 once you
get into the new process. There should be a UserData field that you can
use when you create your new process - make this point to an area of
memory that you can share between the two processes, and then you can
stick anything in the area and then retrieve it in your new task (i.e.
the value from a5). Maybe need to use assembly until you get a5 restored.
Oh, and a3 (being used as a temporary string storage) might completely
screw your program if one process is using the buffer, you get a task
switch and the other starts poking around in it. Could be problems there.
RWE developed a threadlib which might be useful here. However, AFAIK it
only exists in source and I don't even know if it is complete.
---------------------------------------------------------------------
To unsubscribe, e-mail: blitz-list-unsubscribe@netsoc.ucd.ie
For additional commands, e-mail: blitz-list-help@netsoc.ucd.ie