Date: Tue, 31 Mar 2009 09:12:01 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Randall Stewart <rrs@lakerest.net> Cc: threads@freebsd.org Subject: Re: A mutex for inter-process ;-) Message-ID: <Pine.GSO.4.64.0903310901410.6930@sea.ntplx.net> In-Reply-To: <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net> References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <Pine.GSO.4.64.0903301719000.2318@sea.ntplx.net> <AC6F7359-28D5-4F92-93AF-43B6AF86FC01@lakerest.net> <Pine.GSO.4.64.0903301935300.2318@sea.ntplx.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <Pine.GSO.4.64.0903310235580.5671@sea.ntplx.net> <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 31 Mar 2009, Randall Stewart wrote: > > On Mar 31, 2009, at 2:50 AM, Daniel Eischen wrote: > >> >> They define the API. We should not be making new APIs for something >> that already exists, that applications already know how to use, etc. > > So what you are saying is ... just let the application do it. Provide > nothing but the ability to "mark" a mutex as shared. And let the > app figure it out. Correct. We do not need nor want any more SYS V IPC stuff and have more utilities like ipcrm, ipcs, etc to deal with them. POSIX already defines the API for us and tells us how to use process shared mutexes, et al. > Hmm.. If one company is asking for this ability i.e. easily > do shared mutexs I am sure other folks have wanted it as well. > Now rolling your own is a valid thing to do.. but it seems to > me providing something for general use is not a bad idea either. There already is something for general usage, see POSIX ;-) > The pages you pointed out even show such a mechanism for > semaphores... i.e. there definition of > > semaphore_create(char *shared_name) > semaphore_open(char *shared_name) > semaphore_post(..) > > and kin. > > > Curious place for it though.. under pthread_mutex_destroy() ;-) They are also in the POSIX spec under their own entries. > And of course as pointed out this does not solve the quick death > syndrome (for that matter neither did I yet but I am thinking > about this one ;D)... which is the real hard problem.. and really > does require assistance beyond what an application can generally > do... No, the kernel can do it under the existing umutex API. You should really be asking David Xu this stuff, but the kernel can remove any of its own resources (if it has any allocated) when the shared memory is removed, or it may be possible to have POSIX mutex robustness by having the kernel unlock or deallocate umutex resources upon process termination. The point is, it is possible for the kernel to do this, if it already doesn't, using the existing umutex APIs. > IMO having a general library function available is a good thing. If > you are not interested in seeing it in libthr where I think it would > belong.. thats fine I can build a port or other such... > > I will send Julian the manual page after I get it built through :-D There already is an API for doing what you want, and sorry, but no, I don't think adding a BSD-only API that is different from something POSIX already defines is a good thing ;-) -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0903310901410.6930>