On Fri, Sep 18, 2015 at 12:59 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> 2015-09-18 12:05 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> On Fri, Sep 18, 2015 at 11:25 AM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >> >>> >>> It should not be true - the data sender create DSM and fills it. Then >>> set caller slot and send signal to caller. Caller can free DSM any time, >>> because data sender send newer touch it. >>> >> >> But the requester can timeout on waiting for reply and exit before it >> sees the reply DSM. Actually, I now don't even think a backend can free >> the DSM it has not created. First it will need to attach it, effectively >> increasing the refcount, and upon detach it will only decrease the >> refcount, but not actually release the segment... >> > > I am afraid so it has not simple and nice solution - when data sender will > wait for to moment when data are received, then we have same complexity > like we use shm_mq. > > Isn't better to introduce new background worker with responsibility to > clean orphaned DSM? > I'm not thrilled by this idea. We don't even need a worker to do that, as leaked segments are reported by the backend itself upon transaction commit (see ResourceOwnerReleaseInternal), e.g: WARNING: dynamic shared memory leak: segment 808539725 still referenced Still I believe relying on some magic cleanup mechanism and not caring about managing the shared memory properly is not the way to go. -- Alex
