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