Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site oracle.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!oliveb!hplabs!oracle!bradbury From: bradbury@oracle.UUCP (Robert Bradbury) Newsgroups: net.unix-wizards Subject: Re: SHMOP (SYSV) - really shmat(2) Message-ID: <133@oracle.UUCP> Date: Sat, 26-Oct-85 16:22:47 EST Article-I.D.: oracle.133 Posted: Sat Oct 26 16:22:47 1985 Date-Received: Sun, 27-Oct-85 10:37:18 EST References: <2335@brl-tgr.ARPA> <569@riccb.UUCP> Organization: ORACLE Corporation, 2710 Sand Hill Rd., Menlo Park, CA 94025 Lines: 74 Summary: IPC calls are correct (and useful) [long response but necessary] From Roger Noe: > But what worries me is that the (char *)(-1) might be a legitimate value for > a pointer to a character. I think only NULL is required by the language to > never point to anything. The bit pattern for (char *)(-1) could conceivably > be indistinguishable from a successful return value. Why is this not NULL? > Because little minds stuck to their foolish consistency that all system calls > should return -1 upon failure. What they forgot was that all system calls > should return integers! shmat() in particular should have been allowed > another argument, type (char **) in which one could pass &cp. From the XJ311 C Standard, C.2.2.3: "The integer constant 0 is converted to a pointer of the appropriate type that is guranteed not to point to an OBJECT. Such a pointer, called a null pointer, must appear to be equal to the integer constant 0.". From D.1.1: "NULL ... [can be used] as an argument to represent the null pointer". It is highly questionable whether the result of shmat() can be considered to point to an "OBJECT", so it may be perfectly allowable from a C standard point of view to return NULL. I can imagine machines (I&D space PDP11s) where you could detach your data space and attach a shared memory segment at location zero, so NULL (or 0) is a reasonable result from shmat(). At the same time the result of shmat() must be on a SHMLBA boundary. Out of the 8 or so machines we have used this on, the smallest boundary I've seen is a 512 byte boundary, so although (char *)-1 may be a pointer to a character, it is not a legal result from shmat() and may thus be used to indicate failure of the system call. > The interprocess communication primitives included in System V (message > queues, semaphores, and shared memory) are all very messed up. They were > clearly not thought out too well in either their design or implementation. > With any luck, they'll go away soon and be replaced by something that works. > Are they really that messed up? What criteria do you use to judge that? We have used all of the calls (shared memory, messages and semaphores) in implementations of Oracle running on a number of machines. As articles at the most recent USENIX, UNIX Review (8/85) and the Bell System Technical Journal (11/82) indicate, they are critical to the implementation of high performance DBMS packages [and good multi-user real-time games :-)]. If you were to take a look at shared memory implentations on other operating systems (VM, MVS, VMS, AOS, etc), you might find that the UNIX facilities are not all that bad. My complaints with these calls would be: a) The documentation for semaphores is unintelligable, but if you can figure them out they work much better than using a signal/kill mechanism. I think the basic problem is that the call is overloaded. b) The manufacturers do not test the calls. We have found bugs (historically) in releases from AT&T (3B20,3B2), Amdahl (UTS), and Pyramid. c) If you could tell when a process associated with a message queue died (via a signal), you could use messages to replace pipes (they are more efficient). Using an alarm() with a msgget() adds too much overhead. d) You never know where you can attach shared memory segments if you want to put them at fixed addresses. You have to use test programs to determine the valid addresses because they aren't documented. The difference in location and direction of growth of shared memory segments on two supposadly identical machines (the 3B2 and 3B5) is a joke! [However, this is a problem with AT&T's hardware and software people not talking to each other -- not a problem with shared memory.] As far as going away, I sure hope not -- they are in the System 5 Interface Definition. And they really do work (despite Roger's comments). Now, if the Berkeley people would only wake up and put them into 4.3 or 4.4 life would be just great :-). -- Robert Bradbury Oracle Corporation (206) 364-1442 {ihnp4!muuxl,hplabs}!oracle!bradbury