Dynomotion

Group: DynoMotion Message: 6414 From: himykabibble Date: 1/11/2013
Subject: Threading, and Other Things....
Tom,

As I embark on the grand clean-up of my app, I'm tempted to dive fairly deep, and clean up the threading as well. A year or so back, we did get everything working nicely, but I no longer recall clearly *how* it all works, and I can't help but believe it's more complicated than it should be. So, I'd like to discuss how it *should* be done, to see if I can't simplify it a bit.

Any advice on what would be an appropriate threading model for such an app? I've got things that are user-driven (GUI inputs), timer-driven (GUI updates, blinking "LEDs", need to add one for doing MainStatus updates, etc.), KFlop communications, network access (comms with the toolpath display, which is a separate app), and probably a few things I don't even remember. I have the impression that when we first got all this working, we kinda threw in some gratuitous threads just to get things working, but I'd like to now clean it up, and make it more orderly.

A very vague question, I know, but I'm not sure where to start.... Any help or advice welcomed.

Regards,
Ray L.
Group: DynoMotion Message: 6417 From: Tom Kerekes Date: 1/11/2013
Subject: Re: Threading, and Other Things....
Hi Ray,

Good question. But I'm not sure I have the answer.  I don't see the need for any extra Threads at all.  The GUI is already event and timer driven.  I think Windows will only allow one Thread to update the Windows/Controls/GUI anyway.  The GCodeInterpreter creates a Thread to run a GCode Job internally.  This thread also makes the callbacks to update status and backplotting.

Regards
TK




Group: DynoMotion Message: 6419 From: himykabibble Date: 1/11/2013
Subject: Re: Threading, and Other Things....
Tom,

I would LOVE for that to be the answer, but when we went through this a year or so back, we ended up adding a few threads, and quite a few invokes. I just don't recall why....

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
>
> Hi Ray,
>
> Good question. But I'm not sure I have the answer.  I don't see the need for any extra Threads at all.  The GUI is already event and timer driven.  I think Windows will only allow one Thread to update the Windows/Controls/GUI anyway.  The GCodeInterpreter creates a Thread to run a GCode Job internally.  This thread also makes the callbacks to update status and backplotting.
>
> Regards
> TK
>
>
>
>
>
>
> ________________________________
> From: himykabibble
> To: DynoMotion@yahoogroups.com
> Sent: Friday, January 11, 2013 8:19 AM
> Subject: [DynoMotion] Threading, and Other Things....
>
>
>  
> Tom,
>
> As I embark on the grand clean-up of my app, I'm tempted to dive fairly deep, and clean up the threading as well. A year or so back, we did get everything working nicely, but I no longer recall clearly *how* it all works, and I can't help but believe it's more complicated than it should be. So, I'd like to discuss how it *should* be done, to see if I can't simplify it a bit.
>
> Any advice on what would be an appropriate threading model for such an app? I've got things that are user-driven (GUI inputs), timer-driven (GUI updates, blinking "LEDs", need to add one for doing MainStatus updates, etc.), KFlop communications, network access (comms with the toolpath display, which is a separate app), and probably a few things I don't even remember. I have the impression that when we first got all this working, we kinda threw in some gratuitous threads just to get things working, but I'd like to now clean it up, and make it more orderly.
>
> A very vague question, I know, but I'm not sure where to start.... Any help or advice welcomed.
>
> Regards,
> Ray L.
>