Path: utzoo!news-server.csri.toronto.edu!rutgers!mcnc!gatech!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!zaphod!paul From: paul@zaphod.uchicago.edu (Paul Burchard) Newsgroups: comp.sys.next Subject: Re: NeXT equivalent of Shared Memory and Semaphores on SysV Keywords: Shared Memory Message-ID: <1991Mar14.061545.2860@midway.uchicago.edu> Date: 14 Mar 91 06:15:45 GMT References: <71219@microsoft.UUCP> <1991Mar12.170806.4691@noose.ecn.purdue.edu> Sender: Paul Burchard Distribution: usa Organization: Dept. of Mathematics, Univ. of Chicago Lines: 24 In article <1991Mar12.170806.4691@noose.ecn.purdue.edu> songer@orchestra.ecn.purdue.edu (Christopher M Songer) writes: > >Still, sysV IPC compatibility would be nice from a user standpoint >(if not a purist standpoint) and I do hope support for some sort of >kernel service that would allow sysV shared memory emulation (maybe >non-copy on write files....) will come out in future releases. > >-Chris One example: Berkeley's large, free POSTGRES relational database management system uses shared memory extensively. I doubt anyone would volunteer to convert the 100,000+ lines of code to make use of Mach IPC---so this is a lost opportunity for NeXT'ers. (Actually, they use so much shared memory that kernel modification is part of their standard installation procedure, even for SysV-compatible systems!) On the other hand, seeing as I fit the NeXT Perfect Customer Personality Profile :-), when the two are really in conflict, I and my wallet will gladly take the side of ``innovation'' over ``compatibility''. ----------------------------------------------------------------------------- Paul Burchard ``I'm still trying to learn how to count backwards from infinity...'' -----------------------------------------------------------------------------