timeout control with occurrences

[Intaris]

How about having a timeout occurrence as an input for functions which support timeouts?

I am illustrating a single use case with queues (and a notifier) but I would see this as being beneficial to nearly ALL functions with timeout inputs.

Sometimes we'd like to wait for one of a few different functions (an example of mine which springs to mind is the Dequeue primitive).  At the moment we must essentially poll each primitive with a relatively short timeout, see if one responded and then handle accordingly.  This is (for me at least) ugly to look at and introduces polling which I generally don't like.  I'm an events man.

What I propose would be that instead of simply defining a timeout in milliseconds we can define both a timeout (in milliseconds AND an occurrence for the timeout).  If we wire this data to several primitives (all sharing the same occurrence) the first primitive to receive data triggers the occurrence so that the others waiting in parallel return also.

In the case where no data arrives, each function waits the defined amount of time but upon timeout DOES NOT fire the occurrence.  This would cover corner cases where you may want different parallel processes to have different timeouts (Yes there are cases although they may be rare).  It is possible to change the "priorities" of the incoming queues in thie way.

Background info: One example where I could use this is for RT communication.  Here we multiplex many different commands over TCP or UDP.  On the API side it would be beneficial to be able to work with several strictly-typed queues to inject data into this communication pipe while still maintining maximum throughput.  I don't like using variants or flattened strings to achieve this multiplexing.

Being forced to poll means the code must decide between efficiency (low CPU usage) OR response time (setting a very low timeout).  Although the CPU load for polling may be low, it's not something I personally like implementing and I think it's generally to be avoided.

There IS a LVOOP solution to this particular problem but not everyone can use LVOOP in their projects (for various reasons).  I can envisage other use cases where interrupting a timeout would be desireable (Event structure, wait on ms, VISA read and so on and so forth).

Shane.

[Intaris]

Of course in the second picture one could (should) wire "-1" to the timeouts of the dequeue and wait for notifier primitives but I wanted to keep everything visually constant to not add background noise.

[AristosQueue (NI)]

This is among the best suggestions ever submitted to the Idea Exchange, IMHO.

[reddog]

If you had the ability to receive events in the event structure for when N elements are added to the queue, would you still want this feature?  If you had to choose between using the event structure or using this mechanism, which would you prefer?

[Intaris]

AQ, you flatter me.

Spoiler

Go on, do it again....

Regarding the question of the event structure.....  I'm unsure.  I believe both approaches have their validity because having an event structure ONLY for this type of operation seems too much and actually ends up hiding code.  If I am coupling this type of operation with other event operations then I'd certainly go with the event structure.

Int he end I believe that BOTH approaches have merit and it depends on what the programmer wants to finally achieve as to which approach would be best to use.  Please note that I would apply this idea to far more than queues and notifiers.  I would look everywhere there is a timeout and see if this could apply.  I think it could be very widely applied.

[SteenSchmidt]

Magnificent. I've often wished for a way to abort various timed functions prematurely (and thus rolled my own Wait function, as is in the OpenG toolset). This idea is spiced up with co-timed functions handling the inter-notification themselves. Even better.

Kudos!

/Steen

[fabric]

Nice idea 🙂

Just one possible refinement: It seems like it might be useful to allow the timed functions to be configurable to optionally NOT fire the occurrence if they are the first to receive data. That would allow certain functions to act purely as listeners. Any takers? 

[Intaris]

If you want the functions to not trigger each others timeouts, then supply them with different occurrences instead of sharing an occurrence.

[fabric]

---

@Intaris wrote:

If you want the functions to not trigger each others timeouts, then supply them with different occurrences instead of sharing an occurrence.

---

Not quite what I meant... Imagine all my timed functions are waiting on some data, but one of the data sources is "independent" of the others (secondary/optional/non-critical??). If that function is the first to receive data then I still want to wait on one of the other functions, but if any of my other functions receive data then I want my independent function to exit too. 

[Intaris]

So you want node X to timeout as soon as a different node receives data but not to stop others when IT receives data?

Well I'm pretty sure you can do this manually by managing the occurrences being used.  You have independent node X and interdependent Nodes Y and Z.  You simply need to fire the X occurrence as soon as the YZ (others) occurrence fires AND YZ have not both timed out.  Hey presto you can do what you require.

[drjdpowell]

I haven't used occurrences that much, but my understanding is that the waiting nodes could get out of sync if the programmer unwisely put one of the nodes in a case structure (so each node is on a different iteration of the occurrence).  Would it be better to have, instead of a connecting occurrence, a growable primitive that can take multiple queues/notifiers (with a single timeout and multiple strict-typed outputs with some way of indicating which one is none-default)?  That way, the waiting operations are tied together and can't be misused.

-- James