On Thu, Mar 17, 2022 at 3:26 AM IOhannes m zmölnig <zmoel...@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 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list