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 > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription
preferences: http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
