[PD] Choices of IPC when using fast-forward

[Charles Z Henry]

On Thu, Mar 17, 2022 at 3:06 AM cyrille henry <ch at chnry.net> wrote:
>
> Hello Chuck,
>
>
> Le 16/03/2022 à 22:00, Charles Z Henry a écrit :
>
> [...]
>
> >
> > My conclusion there was that shmem can be used for asynchronous
> > inter-process communication with minimal risk to real-time.
> it can also be used between 2 synchronous process!

I see that in the examples now.  You've used [pd~]  and it's pretty
cool how that works.

>   It's very
> > good as a fundamental object--it does not block, it does not
> > synchronize.
> that's the aim!
>
> > Notable limitations:
> > 1. Every process needs to know/use the same size for shmem ID's.
> is that a real limitation?

I was unsure about this ordering, but I have run some tests to clarify.

P1:[allocate ID size(
P2:[allocate ID size(          <-- Order does not matter
P1:[memset array1(          <--
P2:[memdump array2(

You can write the data before the 2nd process has run allocate and it
still works fine.

> Do you have a practicable example where one need to share memory of different size?
>
> > 2. Once allocated, a shmem cannot be re-sized.
>
> There is an allocate message now!
> It allow to change the Id and the memory size.
> But Antoine have problem compiling it on windows, so the last version is only available in deken for linux and osX.
> I'll be happy if anyone else want to gives a try at a windows compilation...

Re-sizing now works great too.  Only thing I noticed was not to send
extra allocate messages in the first process, before the 2nd process
has a chance to run its allocate.

There were also some orderings of allocate on P1 and P2 with different
sizes that still worked, even though that's not really how anyone
should use it.
None of my intentional misuse caused any crashes.

> > 3. Writing to/from an extremely large array all at once poses a risk
> > to real-time.
> yes, obviously, moving data from an memory position to an other need time.
> It's far from ideal, but in this situation of "extremely large array" you can spread over time your read/write.
>
> best
> Cyrille

I think I misused the word "limitations", sorry I used that word.
More like obstacles I was looking at
I was working out some way to hand data around, while only allocating
shmem in 2^N sizes that hang around and get re-used instead of
re-allocated.

I'll work my way up to testing how big a data transfer has to be to
cause a problem to real time