Cool!

let's wait the standard time for deken to share it and test!!!
The package is already online! Deken now updates the cache immediately, you do not have to wait 24 hours anymore.

Christof

On 19.03.2022 15:34, cyrille henry wrote:
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 <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



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to