Path: utzoo!utgpu!watmath!clyde!att!rutgers!ucsd!sdcsvax!ucsdhub!esosun!seismo!uunet!auspex!guy From: guy@auspex.UUCP (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: signals to running processes Message-ID: <560@auspex.UUCP> Date: 2 Dec 88 10:02:51 GMT References: <950@taux01.UUCP> <1263@vsedev.VSE.COM> <555@auspex.UUCP> <1265@vsedev.VSE.COM> Reply-To: guy@auspex.UUCP (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 33 >That may very well be, but I was simply trying to state that >if he does not have System V, chances are he won't have *shared >memory*. Again, not so fast; if you have "shmat", which is what I was "grep"ping for and found in the SunOS "lint" libraries, you presumably have "*shared memory*" - the "shmat" I'm familiar with is, from the SunOS manual page: shmat() maps the shared memory segment associated with the shared memory identifier specified by shmid into the data segment of the calling process. Upon successful completion, the address of the mapped segment is returned. These days, I would think twice before saying "if he does not have System V, chances are he won't have *shared memory*", if "System V" is to be interpreted as "something that began as the stuff from an AT&T source tape, as you seemed to have interpreted it. Looking at the value of SIGUSR1, seeing that it's not 16, and concluding that they're unlikely to have shared memory is a mistake; if they *do* have a system that started out with the stuff from a Berkeley source tape, but that had S5 IPC added, and took the claim that they were unlikely to have S5 shared memory at face value and didn't look for it on their system, they'd have lost. The world isn't neatly divided into "BSD" and "System V"; there are plenty of systems with features from both, many of which may have started from BSD but picked up stuff like S5 IPC. (Of course, in SunOS - and, I think, in at least some other systems, including S5 from AT&T - it's an optional feature, so you have to configure the S5 IPC stuff into your system.)