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