An idea on multithreading implementation

Bob Sneidar bobs at twft.com
Tue Jan 18 19:16:57 CST 2011


This "seems" to work because you are envisioning each call to a command or function in time as running separately. This is an illusion. If any of the commands or functions take longer than one second, say 5 seconds, your calling command will not get control back until the other is done. Because things run so fast in LC and people rarely write code that takes really long times to execute, this is normally not a problem. 

Where it shows up is when you are processing a lot of things, and you want to show some kind of progress bar. Well you can't, unless your process involves a loop and you can make calls to update your progress bar inside that loop. 

But say you were accessing a very large database remotely, and each call to the database took several seconds. Then parsing the data took another couple. Then formatting and printing the report took another 10. Even if you used a send in time, nothing else in LC would happen until those calls were done. 

It REALLY starts showing up in games or graphic oriented things. Right now you have to loop through each object, move one, then the next, then the next, but what if you could call the function that moved each object as a separate thread? Each object would truly be moving independently. 

Again maybe I am not talking about multithreading but multiprocessing or some such thing. 

Bob


On Jan 18, 2011, at 5:00 PM, Alex Tweedly wrote:

> 
> Other than the issue of hitting a breakpoint, can't you simulate this very closely already.
> 
> on addToTimers pMessage, pObject, pFrequency
>    -- store this info
>    put pFrequency &TAB& pMessage &TAB& pObject &TAB& pFrequency & CR after sTimerList
> end addToTimers
> 
> on removeFromTimers pObject
>     -- remove from stored list
>     -- details left as an exercise
> end removeFromTimers pObject
> 
> on pauseTimers
>   put false into gTimersAreActive
> end pauseTimers
> 
> on repetitivelyFireTimers
>    put empty into tNewList
>    if gTimersAreActive then
>      repeat for each line L in sTimerList
>         subtract 1 from item 1 of L
>         if item 1 of L = 0 then
>            send item 2 of L to item 3 of L
>            put item 4 of L into item 1 of L
>        end if
>        put L & CR after tNewList
>     end repeat
>     put tNewList into sTimerList
>  end if
>  send "repetitivelyFireTimers" to me in 1 second
> end repetitivelyFireTimers
> 
> P.S. of course, there should be error checking, and you could handle sub-second (or non-integer second) timers as well - but this general idea
> 
> P.P.S I just typed the above script lines in - not tested, not a technique I generally use.
> 
> -- Alex.
> end repetitivelyFireTimers
> 
> 
> On 18/01/2011 23:57, Jeff Massung wrote:
>> 
>> I - personally - would be much happier if two things were done:
> 
>> *** Create a timer control or some method of doing the same thing in code.
>> It can be sort of simulated right now like so:
>> 
>> send "foo" to me in 5 seconds
>> 
>> on foo
>>   ... do stuff ...
>>   send "foo" to me in 5 seconds
>> end
>> 
>> But this has issues (for example, if I have a bug in "foo" so I fail to send
>> again, or I hit a breakpoint in "foo" and have to stop execution), and
>> sometimes I want to be able to pause send messages, etc. Being able to just
>> create an interval that responds well to various situations would be very
>> desirable:
>> 
>> send "foo" to me every 5 seconds ## done!
>> 
>> suspend the result ## the message is paused temporarily
>> resume the result ## the message will continue from where it left off
>> 
>> Those few things would be very useful to me.
>> 
>> Jeff M.
>> _______________________________________________
>> 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
>> 
> 
> 
> _______________________________________________
> 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




More information about the use-livecode mailing list