Threads (was [OT] - REALBasic Claims 100K Users)

Andrew andrew at ugh.eclipse.co.uk
Thu Oct 5 14:46:19 EDT 2006


On 05/10/2006, at 1:40, Dar Scott wrote:

> What kinds of things might be shared among threads?
> Should a thread communicate with any threads other than its parent?
>
> 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.

There wouldn't need to be any special methods of communication if it 
was done this way. A thread would terminate when the original handler 
completed.

This is just my initial thoughts...there may be flaws I haven't thought 
of. There are still details like how to terminate threads on exit, what 
do do on deadlock (or if it's the programmers job to avoid it) etc to 
be considered.

Andrew




More information about the Use-livecode mailing list