From owner-freebsd-hackers Sun May 31 13:50:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA18932 for freebsd-hackers-outgoing; Sun, 31 May 1998 13:50:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.133.7.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18671 for ; Sun, 31 May 1998 13:49:22 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id NAA23363; Sun, 31 May 1998 13:48:56 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199805312048.NAA23363@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: mike@smith.net.au, rminnich@Sarnoff.COM, doconnor@gsoft.com.au, hackers@FreeBSD.ORG Subject: Re: Star Office Installation In-reply-to: Your message of "Sun, 31 May 1998 20:45:05 -0000." <199805312045.NAA12554@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 13:48:56 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am asking for the linux calls in the emulation layer to behave like they do in linux. Amancio > > > > My next question is , > > > > why so many postings about Star Office without a single soul venturing > > > > into the linux layer to solve at least the ipc shared memory segments > > > > clean up? > > > > > > > > Well, lets chat about it some more 8) > > > > > > By definition, shared memory segments are persistant. > > > > > > It would be an error to delete them when the last reference is deleted. > > > > > > This is arguably a design flaw, but being a design flag, there's really > > > nothing you can do about it. > > > > Well, I guess on Linux star office misbehaves by deleting its ipc > > shared data segments when it exits. > > No, it doesn't. But if FreeBSD deleted them on it behalf when > Star Office exited, FreeBSD would be in error. > > > > Most likely whats going is that we are not handling properly the ipc > > calls or possibly something else which is causing Star Office not > > to delete the ipc shared data segments upon exit. > > You mean "shutdown", not "exit". My point was that SysV IPC is > not resource tracked, and it would be an error for FreeBSD to > resource track it (which is what was being requested). > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message