Date: Sun, 31 May 1998 21:14:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: street@iname.com (Kevin Street) Cc: dfr@nlsystems.com, hasty@rah.star-gate.com, tlambert@primenet.com, mike@smith.net.au, rminnich@Sarnoff.COM, doconnor@gsoft.com.au, hackers@FreeBSD.ORG Subject: Re: Star Office Installation Message-ID: <199805312114.OAA14092@usr06.primenet.com> In-Reply-To: <13681.44921.894518.950536@kstreet.interlog.com> from "Kevin Street" at May 31, 98 03:50:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Setting IPC_RMID is the right thing to do, but the code has to be > somewhat smart about when to do it, because (from man shmctl): > > IPC_RMID Removes the segment from the system. The removal will not > take effect until all processes having attached the > segment have exited; however, once the IPC_RMID operation > has taken place, no further processes will be allowed > to attach the segment. ... > > On Linux it's easier because you don't need to wait until all the > attaches have been done before setting IPC_RMID. The linux emulation > layer must be doing something about this difference in semantics or > we'd probably see lots of failed attaches from Linux code. Linux is in violation of SVID III, aparently, in allowing subsequent attaches... unless FreeBSD is? I don't have my copy handy right now. Do the emulation layers support virtual marking classes of operations? It seems to me that to emulate this behaviour without adulterating FreeBSD's SysV IPC into SVID non-compliance, you would need to: 1) Reference count the segment (already done?). 2) Note that the Linux IPC_RMID had been set, but *not* set it. 3) Establish a handler to be called on exit such that the emulation layer can track resources on behalf of the emulated environment. 4) In the handler, note that the reference count on the segment is transiting from 1->0, and remove the segment. One problem with this is that the exit order may not be such that the setter of the IPC_RMID virtual mark exits last; if so, then the virtual mark needs to be visible to all processes running from the emulation environment. Note: doing this damages the ability to have both Linux and FreeBSD processes communicating via the same segment, such as when running Linux X clients (using the SHM extension) against a FreeBSD X server. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805312114.OAA14092>