I have taken the OOP Plunge...but have a couple of questions

[Daklu]

I agree with James.  Other languages often directly manipulate OS threads and have to deal with the switching overhead.  Labview "threads" are not OS threads.  I call them "parallel execution paths" (PEP) in my head.  Labview manages the OS thread pool under the covers so we don't have to worry about that.

That's the beauty of actor-oriented programming in Labview.  Since PEPs are so cheap and easy, why not take advantage of them?  Create and destroy at will.

[Corny]

Daklu wrote:

When I need a loop to execute an action at regular intervals I create a "timer" loop. It is essentially a loop whose sole purpose is to send a specific message to a specific loop at specific intervals. They are quick to write and it's easy to reason about what is happening. (The loop receives a "tcp read" message every 20 ms.)  One of the AF examples (could be the Cooler...?) has a Timer actor that I believe does exactly that.

I have looked at the AF example of the Cooler, with the timer actor. However if you use this timer to tell the TCP to send an command at a regular interval - and something unexpected happends - outside of our control - that affects the TCP communication and makes it slow/unstable, this timer actor would would eventually start filling up the TCP actor with "send this", "send that" etc.

Isn't that a bit scary - that it does not have any feedback if what it sent actually happened? I am new to the AF and have only leaped into it this weekend (newbie), but as of my knowledge I could not see any types of feedback (send message to caller) to the Time actor in the Cooler example. Any good solutions on to solve this? From my point of view such timed actor should always get a feedback that what it has sent actually has happened?

[Daklu]

Corny wrote:

1. ...this timer actor would would eventually start filling up the TCP actor with "send this", "send that" etc.

2. Isn't that a bit scary - that it does not have any feedback if what it sent actually happened?
3. From my point of view such timed actor should always get a feedback that what it has sent actually has happened?

1.  (I presume you mean the queue would get backed up with "send" messages.)  No it wouldn't.  An actor's message receiving loop is written so it handles all messages "instantly."  If an actor conducts a process that takes some amount of time, that process is implemented in a separate loop (or perhaps a sub actor) internal to the actor.  Nearly all of my actors have a message handling loop and one or more working loops.  If the TCP process went wonky, the message handling loop would still receive "send" messages, but it knows something is wrong so instead of sending a TCP message it might ignore the message or send an error message to its managing actor.

2.  No.  Think of it in terms of responsibilities.  The metronome (a more appropriate name than "timer") has one and only one responsibility--to send a message at regular intervals.  That's all it cares about.  It has no specific knowledge of what the message it is sending means and it specifically is not responsible for making sure the TCP actor acts on it.  One of the core ideas of actor-oriented programming is each actor is responsible for itself.  When the TCP actor receives a "send" message it will react to the message appropriately, depending on its internal state, error conditions, etc.  If the TCP actor needs to announce something, it will send a message up to its managing actor, not the metronome.

3.  The metronome is a helper, not a manager.  One benefit of a metronome is its simplicity.  In fact many times they're not really actors because they don't have a message receiving loop.  It's just a dumb automaton that keeps going until it's exit condition is met.

[David_Staab]

A comment on Daklu's reply to Corny: Daklu is talking about the proper design of Actors, in general. The Actor Framework is best used as a tool for actor-oriented design, but it can't completely enforce that design approach for you. To use the framework appropriately, you'll have to start from the right application design perspective. I wish I could share a link to some reference material on AOD, but I don't know of any. Indeed, I've just kind of osmosed what I know by reading the discussions in this group and talking to people smarter than me.

[Corny]

Daklu & David_Staab

Thanks a lot for the information. A very good explanation A light went up

I really now see the point of the timer and how it hangs together. Also really the point with the actor framework and the word "actor" By only having looking at this last weekend, I'm beginning to get more and more hang of it. Well at least from my point of perspective. Yesterday evening I wrote a fast test application with AF, trying to really get the hang of it, and trying to get to that point where you think: "aahh, so this is how it works, and finally everything fits together". Well that point is stil a bit away.

I really need a "change". my brain is fed up with QSM. I'm puking QSM's all over the place where that is an appropiate solution. Its getting like a bad hangover.

Like today I added a re-entrant QSM for communication in a software that communicates with some types of displays and it really felt horrible doing so, - after having created a small app in AF yesterday and to see the difference. But I couldnt touch the AF pallette due to I far from feel I have it under control and its abilities (and it wouldnt fit in with the rest of the application design of that application anyway - but such I really cant say before I know how the actor framework works and is built up).

Well, back to some more research. I guess some more posts from me will show up on this forum sometime.

[Daklu]

Corny wrote:

I really need a "change". my brain is fed up with QSM. I'm puking QSM's all over the place where that is an appropiate solution. Its getting like a bad hangover.

You remember how as a kid you built a treehouse out of whatever scraps of lumber you could find and ended up with something that mostly works, but is a touch unsafe and you're never quite sure what you'll find when you go up there?  QSM-based code always feels that way to me.  Once you *get* actor oriented programming you may find QSM's are almost never appropriate solutions. 

[Corny]

Hey, dont mess with my tree houses. Currently its a nice, cozy village. We have a caretaker, a blacksmith (who recently plumped out more children), overseer, leaf-collectors, numerous others, and a major called "engine" who kind of runs the place. The village has been through tornados, wind, and fire and is still going strong, and has developed a nice pre-warning system for the natural disasters.

Currently it will be kept like this cozy tree-house village - it would be horrible to the community to start building Las Vegas just besides it. That would create riots and all sorts of shit. But Las Vegas shall and will be built another place when that time comes.

[vishots.com]

Daklu wrote:

Once you *get* actor oriented programming you may find QSM's are almost never appropriate solutions. 

Good thing you put that smiley in there. For a moment there I almost believed you.