Date: Wed, 1 Mar 2000 12:26:52 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Christopher Masto <chris@netmonger.net> Cc: John Polstra <jdp@polstra.com>, current@FreeBSD.ORG Subject: Re: Shared memory - Was: 2 Queries Message-ID: <20000301122652.B26100@orion.ac.hmc.edu> In-Reply-To: <20000301145737.A22521@netmonger.net>; from chris@netmonger.net on Wed, Mar 01, 2000 at 02:57:38PM -0500 References: <20000229021327.E21720@fw.wintelcom.net> <20000229134143.B4903@netmonger.net> <20000301182028.C61034@plab.ku.dk> <20000301124613.A15018@netmonger.net> <200003011928.LAA75785@vashon.polstra.com> <20000301145737.A22521@netmonger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 01, 2000 at 02:57:38PM -0500, Christopher Masto wrote: > > Also, it's persistent for legitimate design reasons, just like files > > are. Applications need to clean up after themselves. > > You can have many more than 32 files. Files are (usually) > well-organized and have names, so you can wipe out your web browser's > cache or lock file relatively easily. Files take up a negligible > fraction of the available file space. That limitation is FreeBSDs fault and is correctable in the kernel config file so it's really the administrator's fault. For instance the default on a recent Irix machine is 600 segments which a maximum size of 512MB each. Solaris has nearly as many. > SysV shared memory is limited, unnamed, unorganized, and uses up a > very scarce resource. Keys provide a limited sort of naming. It's not hierarchical, but it basicaly gives you 2^32 names which can be accessed exclusivly. The resource is only as scarce as the system admin makes it. I don't like FreeBSD's default limits, but they are just that, defaults. > > The OS has no way of knowing whether an application wants its shared > > memory segments to survive after it terminates. > > That's unfortunate. That's one of the reasons I try to stay away from > SysV IPC. I don't like to have to reboot. It would be nice if SysV IPC had a refrence counting mode (though anyone who what they were doing could implement such a thing with a semaphore to do the refcounting which is probalby why they didn't do it). The fact is though, there are significant cases where the OS *cannot* know if the application is done or not. SysV shm is really designed (as far as I can tell) to be a low level API, somewhere around the level of malloc. It's not a complete solution and that's the trap people keep falling into. You have to implement that goop to go around it. It's not really that hard and most of it is write once, use over and over again. If you use ipcrm you don't have to reboot. I've spent the last couple weeks hacking on some code which uses SysV shared memory and semaphores. It's really not that bad. You just have to get into the proper mindset. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000301122652.B26100>