Threads
Luis
luis at anachreon.co.uk
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?
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
>
>
More information about the use-livecode
mailing list