infratec wrote:Extended version without global variables:
Code: Select all
Structure ThreadParameterStructure
Thread.i
Delay.i
EndStructure
Procedure test(*ThreadParameter.ThreadParameterStructure)
Debug "CurrentProcessId: " + GetCurrentProcessId_()
Debug "CurrentThreadId : " + GetCurrentThreadId_()
;Debug "CurrentThread : " + GetCurrentThread_()
Delay(*ThreadParameter\Delay)
EndProcedure
Define ThreadParameter.ThreadParameterStructure
ThreadParameter\Delay = 20000
ThreadParameter\Thread = CreateThread(@test(), @ThreadParameter)
Debug "Outside Thread: " + ThreadParameter\Thread
Debug "Outside ThreadID: " + ThreadID(ThreadParameter\Thread)
Delay(25000)
Since you need (normally) always parameters, you can add them in the structure.
This code part is right.
I have two remarks about these recent questions.
1) I recommand dynamic pointors, even in basis (out of procedures)
Code: Select all
Structure Root
Head.I
Map aMap.Key()
Array anArray.Field(0)
EndStructure
Define *R.Root = AllocateStructure(Root)
CreateThread(@ObjectCreate(), *R)
; etc...
This allows a "perfect" (near one integer) memory managing of maps and arrays.
This allows any backup, swap, levelling or thread buffer root.
2) I think about such any questions about links between thread clients and process.
Now, I realize : if anybody began his coding by single procedures with specific arguments, without bus neither common argument, so there is a real converting problem to thread these procedures if a ThreadId() function is missing.
In this way (but it was not explicit in the question),
Threaded could be used to prevent from variable name conflict,
Global.ThreadStructure *P to share all information between every thread. (There is just a problem of data security)