Why isn't self-enqueing taboo?

[ConnerP]

So there is some contention about the point of self enqueing. It can be confusing:

Queued State Machine: basically essential, the exception being always returning directly to a event handler state
Queued Message Handler: NEVER

Actor Framework: Standard procedure(?)

I'm curious, since actors act like separate QMHs, why is it okay that they self-enque?

[Oli_Wachno]

I don't see, why self enqueing should be a taboo. It IS used with the QMH.

Also taught in LabVIEW Core 2 & 3.

[Eric.M]

---

@ConnerP wrote:

Queued Message Handler: NEVER

---

I'm curious about your statement. Can you post a picture or give us examples? As Oli said, one of the core principles of a QMH is being able to self-enqueue messages depending on events occurring (like user interactions)...

What could be subject to a debate is unconditional self-enqueuing messages: sending a message to itself without any prior condition checking (e.g. the QMH/Actor/... state). I personally don't like it. I'd rather spawn a helper loop or a daemon that runs when my software component receives a Start/Pause/Stop message.

--Eric

[Taggart]

It is taboo because when you self enqueue you can't guarantee that another state/message won't execute in between.  Maybe you don't care, but I would argue often you do.

As for AF, it is certainly not standard practice (as far as I can tell).  If you need to send yourself a message you can just call the method because that is all the message does anyway.

Perhaps we are confusing terms.  When you say self-enqueue I interpret that as sending a message from the loop that does the dequeue.  That is what is taboo.  A helper dropping a message into the queue is perfectly normal and encouraged in both the AF and DQMH.

[Ironman_]

It's not taboo.

Taboo is a meme, it's drastic.

The correct answer is: IT DEPENDS

Sincerely,

the best software developer of the entire forum

[Taggart]

I'm just curious what is the use case for self-enqueueing?  I'm having trouble coming up with one that can't be solved in a better way...

[drjdpowell]

---

@Oli_Wachno wrote:

I don't see, why self enqueing should be a taboo. It IS used with the QMH.

Also taught in LabVIEW Core 2 & 3.

---

Why this common feature is a flaw is one of my favorite criticisms of NI's various templates.   The first 10 minutes of this talk, for example, I show how easy it is to make a race condition.   Though at the end of the same talk I show how one does sometime want to send a (delayed, usually) message to oneself.

[Taggart]

That was a great presentation.  I enjoyed it.  I do have one question.  The whole time you were talking about achieving subvi-like behaviour for your "protected" sections of actions.  My question is, why bother using the queue at all?  Why not just make each action a subvi and have that initial action be a subvi that calls the subvis from all the other actions?  Is there some reason I am missing not to do that?

[drjdpowell]

Going with subVIs is a strong option (and what an AF user should be doing).  Personally, I prefer the closer connection to the front panel and (IMO) better readability of having all high-level code of an "actor" on one block diagram.

[Taggart]

That makes sense.  I figured you had a good reason for doing it that way.