Hello, Antoine finality found the bug in my code that prevent the windows compilation.
So shmem 1.1 is finally out!
Thanks to Antoine wizardry and some magic in github, a package was automatically upload to deken with binary for everybody!
let's wait the standard time for deken to share it and test!!!
cheers C
Le 17/03/2022 à 18:04, Charles Z Henry a écrit :
On Thu, Mar 17, 2022 at 3:26 AM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 3/17/22 08:58, cyrille henry wrote:
Notable limitations:
- 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