viktoras at ekoinf.net
Thu Oct 12 19:25:56 EDT 2006
Why shouldn't it work?
Threads can be produced by cloning an invisible substack (named "thread")
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
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!
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?
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 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
> Computer programming
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
More information about the use-livecode