[PD] Choices of IPC when using fast-forward

[cyrille henry]

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!

  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?
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...

> 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'd like to write a pair of management abstractions for using fast
> forward and shmem, then, that make it easy to stage in/out large,
> variable-length data
> 
> Anybody else have best practices for IPC when using fast forward?
> Having a listener on the 2nd process between computing sprints in the
> "fast forward" process completely changes how I can do things.
> 
> other: is there a good way to start/stop processes other than
> [ggee/shell]? cross-platform?
> 
> Chuck
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> .