Let's ignore for a second that the alternatives mentioned were notifiers or local variables. Those are both inferior to queues for what we've been told thus far. We can also ignore that each of these would be polled for the sake of the discussion.
Why would you poll the queue? The event driven nature certainly doesn't dictate that. There's no need to add the timeout to the dequeue element simply because the input is based on events. I don't have LV here to verify. But, I'm fairly certain the dequeue element function operates similar to the event structure in that it sits idle waiting for input. When there's something in the queue, it operates. When there's nothing there, it sits and waits. In my experience, they blend rather well with multiple loop communication when I care about lossless data.
Now, let's assume my understanding is wrong. There's no way to avoid polling the local variables. You aren't even afforded the luxury of using the timeout to wait. You must continue to poll this. The notifier works the same as the queue, except that it only has a buffer size of one. If we have to poll a queue, we have to poll the notifier. We can miss data points with the notifier if they come in fast enough where we'd collect those points and compute them later with the queue. Their benefit over queues is if you want to send the same data point to multiple other loops. They work well with a single writer, multiple readers. They don't offer any efficiency over a queue with a single loop reading. In fact, the example you referenced will use queues. Not only will the producer/consumer use queues, it has a template for event driven because queues don't require the polling you're suggesting.
With that, I'm curious. Where exactly are you polling queues.. and why?
