Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!cfa!wyatt From: wyatt@cfa.harvard.EDU (Bill Wyatt) Newsgroups: comp.unix.wizards Subject: Ultrix 1.2 and shared memory Message-ID: <596@cfa.cfa.harvard.EDU> Date: Sun, 28-Jun-87 12:44:24 EDT Article-I.D.: cfa.596 Posted: Sun Jun 28 12:44:24 1987 Date-Received: Sun, 28-Jun-87 18:39:54 EDT Organization: Harvard-Smithsonian Ctr. for Astrophysics Lines: 38 I have recently been using Ultrix 1.2 shared memory features, and I've come across a bug or misfeature that I'd like comments on. I've got a set of programs running asynchronously that pass data (usually in only one direction) about status, etc. While this could have, in most cases, been done with writes on sockets, etc., I decided a cleaner and more efficient implementation would be to use Ultrix's Sys V shared memory compatibility features. All programs agree on a unique identifier, they link in the shared memory segment, and you're set. Except, malloc() seems to break (sometimes). I turns out that the shared memory attach function selects a region of memory 32K above the current data break, and if you want to malloc more memory, you're out of luck. I've tried attaching to a specific address (on a page boundary), and it works, but malloc is still broken. I've tried issuing sbrk() calls explicitly after the shared memory attach, but it fails too. Looking at the file shows a structure that gives information on the defaults such as how high above the data break to put the first shared memory segment, but there is no (documented) system call to read that information, much less change it! So, while I can work around the problem (detaching memory, malloc() what I need, re-attaching, blech!), that's not always going to be possible. I probably could specify an address way above the break, but that's not solving the fundamental problem, just putting the reckoning off a bit. Malloc and shared memory in Ultrix 1.2 seem to be incompatible. Is this true, or am I missing some better way of handling their interactions? Any comments appreciated. -- Bill UUCP: {seismo|ihnp4}!harvard!cfa!wyatt Wyatt ARPA: wyatt@cfa.harvard.edu (or) wyatt%cfa@harvard.harvard.edu BITNET: wyatt@cfa2 SPAN: 17410::wyatt (this will ukuku