Threads

Alex Shaw alex at harryscollar.com
Fri Oct 13 02:51:45 EDT 2006


Hi

Was wondering how rev performed on these new dual/quad/multi core CPUs 
which are becoming standard in new systems.

Am hoping for a smoother interface experience by starting to do more 
process-slashing of long running functions by breaking them down and 
using more "send" calls to recursively munch data.

I know rev doesn't do threads and I don't think it needs to but I would 
like to think that it handles it's internal messages efficiently.

I posted the above to the improve-list previously but the link below is 
new :)

http://blog.labnotes.org/2006/08/29/why-processes-scale-better-than-threads/

Viktoras: When you use "go stack", as far as I know, the loaded stack 
just joins the message queue of the current (calling) rev process 
(standalone or ide).

Maybe we need..

go stack "blah1.rev" as modal run as thread

&/or

go stack "blah1.rev" as modal run as process

I too am keen to write powerful server solutions with rev without having 
many smaller server instances sharing the load. Good load balancing code 
to sync many servers isn't my idea of fun.

regards
alex

Viktoras Didziulis wrote:
> Why shouldn't it work?
>  
> Threads can be produced by cloning an invisible substack (named "thread")
> with 
> a handler and renaming the clones to thread_1, thread_2, etc... If this
> makes any sense to 
> anyone the code is free to explore (Rev studio 2.7):
>  
> go stack url "http://www.ekoinf.net/inv/threading.rev"
>  
> or compiled for windows 
> http://www.ekoinf.net/inv/threads.exe 
>  
> The main stack contains a field which displays status of threads and 
> indicates when a thread finishes its job. Any number of threads can be 
> specified. I tried with 100 and it was OK (~100 kb memory footprint). The
> task was simple 
> - parent generates and sends a random number within range 1..10. Process in 
> a thread takes that number and sends it back to a handler in the parent in 
> an equivalent number of seconds. The parent displays status of all threads 
> and cleans up when all threads are finished. 
>   
> All the best! 
> Viktoras 
>  
> -------Original Message------- 
>  
> From: Luis 
> Date: 10/12/06 13:19:40 
> To: How to use Revolution 
> Subject: Re: Threads 
>  
> Maybe this could be done, albeit in a rather primitive way: 
>  
> Separate standalones communicating with each other? 
>  
> Cheers, 
>  
> Luis. 
>  
>  
> Dar Scott wrote: 
>> On Oct 5, 2006, at 12:46 PM, Andrew wrote: 
>>>> What kind of communication? 
>>>> "Do this and let me know when you are finished." 
>>>> "Do this, show progress, and let me know when you are finished." 
>>>> Bidirectional message queue. 
>>>> Send messages to a thread in 'send' style. 
>>> My initial idea would be that when you send a message you could do so 
>>> indicating it should be run it it's own thread (or in an existing 
>>> thread that you know the name of). By default each object (button, 
>>> field, card etc) would have a mutex that you must hold to update it's 
>>> attributes or to run any of its handlers (this would be acquired 
>>> automatically). It would be possible to do finer grained locking if 
>>> the programmer took the trouble to code it. The automatic acquisition 
>>> of locks would be dependent on some global property (that might also 
>>> be used to permit the creation of threads in the first place) so there 
>>> would be no overhead for non-threaded stacks. 
>> I think something like that might work, however I wonder what the right 
>> way would be to make this fit into the Revolution way of things and to 
>> ward off potential problems. 
>>
>> It might start off simple, perhaps between sort of between a thread and 
>> a process in which a library script is used to create a thread and 
>> messages (like with send) are sent back and forth. The shared resources 
>> might be added based on that. Same with accessing objects. 
>>
>> That is far from being able to access anything the home thread could, so 
>> folks might think that too weak. 
>>
>> Dar 
>>
>> -- 
>> ******************************************* 
>> Dar Scott 
>> Dar Scott Consulting and Dar's Lab 
>> Lab, office, home: +1 505 299 9497 
>> Fax: call above first 
>> Skype: send me a note first 
>>
>> http://www.swcp.com/dsc 
>> Computer programming 
>> ******************************************* 
>>
>>
>> _______________________________________________ 
>> use-revolution mailing list 
>> use-revolution at lists.runrev.com 
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences: 
>> http://lists.runrev.com/mailman/listinfo/use-revolution 
>>
>>
> _______________________________________________ 
> use-revolution mailing list 
> use-revolution at lists.runrev.com 
> Please visit this url to subscribe, unsubscribe and manage your subscription
> 
> preferences: 
> http://lists.runrev.com/mailman/listinfo/use-revolution
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> 



More information about the Use-livecode mailing list