An idea on multithreading implementation

[Bob Sneidar]

Very un-livecode-ish. 

Bob


On Jan 18, 2011, at 5:16 PM, Kee Nethery wrote:

> 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode