An idea on multithreading implementation

Bob Sneidar bobs at twft.com
Mon Jan 31 13:35:07 EST 2011


I don't understand how you could have a deadlock. If you mean call something from one threaded stack which in turn calls something in the first threaded stack, then I would say, don't do that! Same as I would say, don't write an infinite loop! Sure you can, why would you?

Bob


On Jan 31, 2011, at 10:25 AM, Geoff Canyon Rev wrote:

> How would you handle race conditions and deadlock in a livecode-like way? If
> the engine could make it as easy as "with new thread" that would be awesome,
> but I think we'd also need ways to prevent/handle the issues that come with
> concurrency.
> 
> gc
> 
> On Mon, Jan 31, 2011 at 11:56 AM, Bob Sneidar <bobs at twft.com> wrote:
> 
>> When I started this whole thread, what I had in mind was a simple method
>> for allowing commands and even whole stacks to run concurrently with other
>> stacks, while still being able to communicate with each other through the
>> engine. All the stuff about enabling and disabling communications between
>> things is to me irrelevant. Just compile 2 apps and they will not be able to
>> talk natively to each other. Done deal.
>> 
>> Some tell me that multithreading is not that simple. Well nothing under the
>> hood of any app is simple, and triply so for a development environment. My
>> idea was for the engine to handle communications between all of it's objects
>> the way it does now, but have concurrent processes IF YOU WANTED.
>> 
>> By default, I envision LiveCode working just the way it does now, with the
>> OPTION to say something like:
>> 
>> open stack "Accounts Receivable" with new thread
>> or
>> do ReportGen with new thread
>> 
>> I could then check in on the state of a global from time to time in my
>> Progress Bar modal stack or switch back to my "Order Entry" stack and
>> continue entering my customer's order while the report generator was
>> running. See? I personally do not have any interest whatsoever managing all
>> the threading myself. I use LiveCode so I do not HAVE to know or understand
>> that sort of thing. I am only one person. One of the things that LiveCode
>> allows us to do, which is not talked about much, is to produce really nice
>> and functional applications with incredibly minimal resources (like only one
>> developer!)
>> 
>> Bob
>> 
>> 
>> On Jan 31, 2011, at 9:35 AM, form wrote:
>> 
>>> Even discounting games, I'd love to be able to designate a substack to
>> being
>>> "threaded", disabling its access to objects in other stacks, and limiting
>>> communication to event/message passing.
>>> 
>>> It would be very much like using the open process command with a Windows
>>> command line program. (WHY doesn't it work with Mac command line
>>> programs?!?!)
>>> 
>>> I use open process is a stack to start a makefile and monitor its output
>>> while keeping the interface perfectly responsive. I do the same on a mac
>>> using a shell command outputting to a text file that I sample the tail
>> from
>>> in another shell command. Hackier, but it gets the basic job done.
>>> 
>>> But if I have LiveCode that I want to start and monitor, I'm out of luck.
>>> (Without getting REALLY hacky, that is.)
>>> 
>>> ~ Chris Innanen
>>> ~ Nonsanity
>>> 
>>> 
>>> On Mon, Jan 31, 2011 at 11:57 AM, Bob Sneidar <bobs at twft.com> wrote:
>>> 
>>>> Well now that there is Livecode for iApps, a lot of people may want it,
>> but
>>>> I for one am never going to develop a game, even a simple one.
>>>> 
>>>> Bob
>>>> 
>>>> 
>>>> On Jan 29, 2011, at 5:06 PM, Alejandro Tejada wrote:
>>>> 
>>>>> Hi All,
>>>>> 
>>>>> It's nice to read discussions about features that
>>>>> enhance this platform, but now I have one doubt:
>>>>> 
>>>>> How many developers (who use Livecode) want
>>>>> to see this platform converted in a game engine?
>>>>> 
>>>>> Notice that the only DLL in my wish list for this
>>>>> platform is a SWF player, that allows to run
>>>>> movies inside a stack, just like the Quicktime
>>>>> externals. I do not want to see a Timeline
>>>>> in this platform...
>>>>> 
>>>>> At least in my mind, you could not build (easily)
>>>>> the kind of applications created with Livecode
>>>>> if it were a game engine. Am I wrong?
>>>>> 
>>>>> Or There are no boundaries anymore among
>>>>> Software Development tools?
>>>>> 
>>>>> Al
>>>>> 
>>>>> _______________________________________________
>>>>> use-livecode mailing list
>>>>> use-livecode at lists.runrev.com
>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>> 
>>>> 
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> use-livecode at lists.runrev.com
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list