[PD] Choices of IPC when using fast-forward

Charles Z Henry czhenry at gmail.com
Thu Mar 17 18:04:02 CET 2022


On Thu, Mar 17, 2022 at 3:26 AM IOhannes m zmölnig <zmoelnig at iem.at> wrote:
>
>
> On 3/17/22 08:58, cyrille henry wrote:
> >
> >> 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?
>
> i don't think this is the problem that chuck is referring to.
> afaiu, it's rather that the two processes need to have a priori
> knowledge of two different "thingies" in order to share some memory
> (without bad surprises): the ID and the size.
>
> from a UX pov the question is, why it's not possible to only have to
> share a single "thingy" (the ID) and have the others be shared implicitly.
>
> fmgdsaf
> IOhannes

Yes, it's exactly that--there's always at least one shared piece of
information that's hard-coded in both patches, if you want to
communicate solely through shmem.  It's trivially extended though.
All processes agree to read from one chosen shmem ID of size 2 on
startup and know that it contains the ID/size of a variable-length
shmem that's now known.  Before you know it, you're writing a whole
protocol.

What's the best method for callbacks from a process that has completed
its task and has data ready to be staged out?
The toplevel process has to be able to be reached from multiple
processes--so that seems like it should just be a udp port.  Unsure on
this point, though

Best,
Chuck





More information about the Pd-list mailing list