[PD] shmem V1.1 is out, WAS Re: Choices of IPC when using fast-forward

[cyrille henry]

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 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
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list