Threads

[Viktoras Didziulis]

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