Pub/Sub in AF ?

[drjdpowell]

What do you mean by "thread friction", AQ?

Comment: Logging is a special case in that it doesn't involve communication between parts of an app.  Information is written to the log possibly from many places, but nothing in the app is reading and acting on that information.  

[AristosQueue]

---

@drjdpowell wrote:

What do you mean by "thread friction", AQ? 

---

Where one thread is waiting for another thread because the second thread is holding some critical resource -- calling a non-reentrant subVI or accessing a shared refnum.

---

@drjdpowell wrote:

Comment: Logging is a special case in that it doesn't involve communication between parts of an app.  Information is written to the log possibly from many places, but nothing in the app is reading and acting on that information.  

---

I tried to emphasize that a couple times earlier. 
"particularly since the receiver isn't acting on the contents of the log"
"Log messages that aren't acted upon have the option to take a shortcut."

[drjdpowell]

---

@AristosQueue wrote:

---

@drjdpowell wrote:

What do you mean by "thread friction", AQ? 

---

Where one thread is waiting for another thread because the second thread is holding some critical resource -- calling a non-reentrant subVI or accessing a shared refnum.

---

---

But what does that have to do with Logging, necessarily.  Do you mean all modules would be posting on the same "to logger" queue refnum?

[AristosQueue]

---

@drjdpowell wrote:
But what does that have to do with Logging, necessarily.  Do you mean all modules would be posting on the same "to logger" queue refnum?

---

Yes. It's tiny, but it builds up... the more modules that need to access that refnum, the higher the likelihood of two trying to access it at the same time and one of them having to wait. In exactly the same way that changing a non-reentrant subVI to be reentrant can help performance, separating communications into separate channels (queues, notifiers, events, TCP, etc) can help performance. Logging is one of the very few legit cases of a ubiquitous communications channel, so it raises the specter of thread friction becoming a noticeable drag on the system. It's not always a problem, but it is a risk to keep an eye open for. 

[paul.r.r]

---

@drjdpowell wrote:

What do you mean by "thread friction", AQ?

Comment: Logging is a special case in that it doesn't involve communication between parts of an app.  Information is written to the log possibly from many places, but nothing in the app is reading and acting on that information.  

---

Most of the applications I write include a page that displays log information, including the ability to filter or search through log entries. The logger design I use includes the log API, which is distinctly separate from log 'sinks' which is where log entries end up. You could have thread friction on the enqueue log entry, but I can't imagine thats a real concern in most applications. That log entry is then passed to individual sinks in an asynchronous thread - the UI component that displays log entries registers a queue sink, then uses that queue as a buffer for displaying entries. 

[paul.r.r]

---

@BertMcMahan wrote:

---

What's the best way to write a general purpose logger that doesn't force every actor that uses it to include message forwarding code? Or, perhaps am I asking the wrong question- is it actually good practice to force the message through the actor tree?

---

Open source and free to use, the design is heavily inspired by the design of log4J and python's logger. I don't like using APIs where the details of implementation are exposed to the user of the API - giving the logger queue (whether its an AF queue or not) out to consumers seems like a code smell to me. I prefer a well defined and encapsulated API - log init, log, log close etc, rather than enqueue log event to this queue that you can also send whatever other message you would like as well. 

https://bitbucket.org/composedsystems/composed-event-logger/src/master/

[AristosQueue(NI)]

> You could have thread friction on the

> enqueue log entry, but I can't imagine

> thats a real concern in most

> applications.

It can be. Common? No. But make your loop requirements tight enough and/or your modules parallel enough, yes, it can become an issue. And it’ll probably take forever to diagnose when it happens because it is so unexpected. 🙂