An idea on multithreading implementation

[Geoff Canyon Rev]

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
>