[LV2] [RTID] proposal for a 'real time ID' extension

[David Robillard]

On Thu, 2016-08-25 at 00:28 +0100, Harry van Haaren wrote:
> On Thu, Aug 25, 2016 at 12:12 AM, David Robillard <d at drobilla.net> wrote:
> > > The extension is as simple as it can get: A single function which
> requests the
> > > next integer ID from the host whereby the function MUST be RT-safe,
> > > non-blocking, lock-free and wait-free. New RTIDs may be requested in
> any of the
> > > many LV2 thread groups.
> >
> > I doubt the latter requirement is possible to achieve for anything but a
> > trivial atomic integer increment.  Is that good enough for fancy use
> > cases with many plugins operating in parallel on distinct event streams?
> 
> That doesn't really scale well - at least not if we're talking lots of
> messages. Assuming the RTIDs are not monotonically increasing, a host can
> "reserve" a bunch of IDs for a particular core, use them from the reserved
> pool until they run out, and reserve again.
> 
> This implies that the RTID is *just* a tag, and *only* a tag. The result is
> that recieving tags out of order, backwards, forwards, etc, is all valid
> usage of RTIDs.
> 
> If we're all cool with that, then no problem :) -Harry

This is the sort of thing that gets incredibly complicated very quickly.
This is part of my hand-wavey instinct to at least stick a flags
parameter in there so we can do things like reserve the top n bits for
something or other later if necessary.

I'm not (yet) familiar with the sorts of use cases that motivated
Hanspeter, but it knee-jerk-seems to me that if you have complicated
graphs of many plugins processing request/response streams, one of two
things is bound to become necessary:

1) Requirement for a separate "stream ID" property to allow multiplexing
without any loss of information, and allowing a simple monotonically
increasing atomic sequence number to suffice

2) Host rewriting of sequence numbers

If 2 is even theoretically possible, it's certainly very unpleasant.

It's worth noting that as far as the directly plugin related transport
mechanisms are concerned, preserving order is a given anyway, so the
usual issues with this sort of thing over networks do not apply, but of
course it's possible to stick a network hop in there (which is a key
benefit of being able to serialize this stuff, and is how Ingen works
remotely)

-- 
dr