On Fri, 26 Oct 2012 11:16:30 -0500
David Ashley <[email protected]> wrote:
> Look at the man page for sem_unlink. All it does is break the
> association between the name and the semaphore itself. If the
> semaphore is still open then it is still accessible and the semaphore
> will be destroyed after the last process closes it.
>
I agree.
> The only thing sem_unlink actually does is prevent any other process
> from opening the named semaphore after sem_unlink is called because
> the name association is broken. It does not have anything to do with
> destroying the semaphore
I agree.
> ...and is not necessary to call prior to
> the last close because that close will unlink the name as well as
> destroy the semaphore.
>
Nope. sem_close does not destroy the semaphore. Only sem_unlink does
when the last mutex client has gone.
First of all: rxapi doesn't own the semaphore.
Because:
I call my initial script which does SysCreateMutexSem("Sem_A"), and
SysCloseMutexSem() in the end. If rxapi would hold the semaphore then
the next call to my script would not be able to create the mutex
because the initial sem_unlink() would not work and thus sem_open() in
SysCreateMutexSem() wouldn't work. But the semaphore will be created.
If sem_close would delete the semaphore then calling my script with a
corrected rexx (i.e. SysCreateMutexSem without unlink) would be
successfully create the mutex anew. But it doesn't. I have tested it.
--
Manfred
the
semaphore does still exist.
If I call it the first time then then the
I wrote a small C program that
> David Ashley
>
> On Fri, 2012-10-26 at 17:48 +0200, Manfred Lotz wrote:
> > On Fri, 26 Oct 2012 10:03:52 -0500
> > David Ashley <[email protected]> wrote:
> >
> > > As long as the creator closes the semaphore everything will be ok
> > > - the semaphore will be unlinked and removed from the system. The
> > > creating process is the owner of the semaphore as far as removing
> > > it from the system.
> > >
> >
> > The sem_close man page states:
> >
> > sem_close() closes the named semaphore referred to by sem,
> > allowing any resources that the system has allocated to the calling
> > process for this semaphore to be freed.
> >
> > sem_unlink man page has:
> > sem_unlink() removes the named semaphore referred to by name.
> > The semaphore name is removed immediately. The semaphore is
> > destroyed once all other processes that have the semaphore
> > open close it.
> >
> > That is why I think sem_close does not eventually delete the
> > sempahore but it should be possible to trigger sem_unlink.
> >
> >
> > > In reality I believe that the rxapi process actually owns the
> > > semaphore and when the process ends it should attempt to remove
> > > all open files/pipes/semaphores/etc. Rick should be able to
> > > confirm this.
> > >
> >
> > I don't know. Let's see what Rick says.
> >
> >
>
--
Manfred
------------------------------------------------------------------------------
The Windows 8 Center
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
