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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
.
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
