My two cents on how Livecode could implement this is to mimic the get URL and
URLstatus functionality paired with functions. For example:
This is a simple pseudo-code example of calling a threaded function 7 times and
then waiting until all 7 threads are complete:
on domythreads
global lat,long,countryName
put myThreadFunction(1,lat[1],long[1]) into countryName[1]
put myThreadFunction(2,lat[2],long[2]) into countryName[2]
put myThreadFunction(3,lat[3],long[3]) into countryName[3]
put myThreadFunction(4,lat[4],long[4]) into countryName[4]
put myThreadFunction(5,lat[5],long[5]) into countryName[5]
put myThreadFunction(6,lat[6],long[6]) into countryName[6]
put myThreadFunction(7,lat[7],long[7]) into countryName[7]
repeat until threadStatus(1) = "complete" \
and threadStatus(2) = "complete" \
and threadStatus(3) = "complete" \
and threadStatus(4) = "complete" \
and threadStatus(5) = "complete" \
and threadStatus(6) = "complete" \
and threadStatus(7) = "complete"
wait 1 second
end repeat
end domythreads
This is what I envision the generic thread call looks like, similar to a
function except it has a unique ID and it cannot use globals or data in the
stack. Everything it is going to use has to be passed into it as a parameter.
thread myThreadFunction requiredThreadIdParameter, optionalThreadParameter1,
optionalThreadParameter2, etc.
set threadStatus = "started" -- allow the thread to communicate while it is
working
do stuff
call functions in the stack that do not have globals nor use data stored in
the stack
send to commands to objects in the stack that do not have globals nor use
data stored in the stack
no reads or writes from any field or button data stored in the stack
set threadStatus = "almost done"
OK to get or write stuff from/to external things like URLs or serial ports or
files
package up a result
return allTheResults
-- after the return the status goes to "complete"
end thread
The way I see it, thread is like a function. You give it a unique ID
(requiredThreadIdParameter) and then call it with the parameters you want it to
have. What would happen next is Livecode would execute the scripts using the
scripts in the stacks that are marked as thread safe using the data provided as
parameters.
The other part to this is the threadStatus function. In the above example the
code just looks for the status to be complete but since the thread can set
threadStatus, the main program can watch it's progress.
I guess my final thread request would be a way to kill a thread that has gone
rogue. For example, perhaps a function like
killThread(requiredThreadIdParameter)
As I see it, each function or command (or thread) in a script would get a
marker declaring it thread safe or not. A thread could only call thread safe
code. If the code had a global in it, not thread safe. if the code looked in a
field, not thread safe.
Anyway that's my two cents on multithreading if I ruled the Livecode world.
Seems like it would be easy enough to implement in the existing code base but
still quite powerful.
I do something similar to this with URLs. A stack running as a HTTP server /
cgi gets hit and it doles out a bunch of URL requests to various other servers.
All those servers work in parallel and when they are done and the urlStatus for
each request is "cached", I grab the results and return a summary to the client.
Kee Nethery
not holding my breath.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
