Date: Fri, 8 Sep 2000 22:28:28 +0100 From: void <float@firedrake.org> To: John Toon <j.a.toon@btinternet.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Shared Memory Issues Message-ID: <20000908222828.A32477@firedrake.org> In-Reply-To: <39B8EFFA.785E6D46@btinternet.com>; from j.a.toon@btinternet.com on Fri, Sep 08, 2000 at 02:56:10PM %2B0100 References: <39B4BD1D.676139D4@btinternet.com> <20000905230110.A9425@host.cer.ntnu.edu.tw> <39B58ABD.1B215190@btinternet.com> <39B7C08B.5841BA62@linkline.com> <39B8EFFA.785E6D46@btinternet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 08, 2000 at 02:56:10PM +0100, John Toon wrote: > > However, it seems strange that you're getting non-attached memory > segments. Surely it is the job of the kernel to clean up after processes > (if they're badly programmed and don't do it themselves)? Perhaps one > program is leaking? SysV shared memory segments are defined to stick around until some appropriately-privileged user process deletes them. I was thinking recently that it might be nice to extend that API so a process creating such a segment could ask the kernel to reference-count it and delete it if the refcount goes to zero, but any app that wants that behavior can just use mmap() anyway, which has the advantage of being portable. -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000908222828.A32477>