Luis luis at
Thu Oct 12 06:19:23 EDT 2006

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
> -- 
> *******************************************
> 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
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:

More information about the use-livecode mailing list