Hi there,
I think I have found an error in the mutex routines in Rexxutils under
Linux.
Rexx is: Open Object Rexx Version 4.1.1, Build date: May 21
2012, Addressing Mode: 32
To show the error I created a small script like this:
/* REXX */
sem = Sem_A
hdl = SysCreateMutexSem(sem)
if hdl =
I found an error in SysOpenMutexSem under Linux.
When getting a handle from SysOpenMutexSem the next call using that
handle gives a segmentation fault.
I think that the last statement in SysOpenMutexSem must be
return context-Uintptr((uintptr_t)semdata);
instead of
return
I disagree with this assessment. I believe the second call to
SysVreateMutexSem should fail because the semaphore already exists. The
second script should be using SysOpenMutexSem to get access to the
existing semaphore.
I believe that the Windows version of this would cause the second script
to
I believe Manfred is correct on this one. I am not sure how this ever
worked. And the fix applies to both the Windows and *nix versions.
David Ashley
On Fri, 2012-10-26 at 09:09 +0200, Manfred Lotz wrote:
I found an error in SysOpenMutexSem under Linux.
When getting a handle from
On Fri, 26 Oct 2012 08:49:09 -0500
David Ashley w.david.ash...@gmail.com wrote:
I disagree with this assessment. I believe the second call to
SysVreateMutexSem should fail because the semaphore already exists.
The second script should be using SysOpenMutexSem to get access to the
existing
On Fri, Oct 26, 2012 at 10:01 AM, David Ashley w.david.ash...@gmail.comwrote:
I believe Manfred is correct on this one. I am not sure how this ever
worked. And the fix applies to both the Windows and *nix versions.
His fix is a little more complicated than required. It should just be
return
On further review we have some other problems as well.
The same problems described in Manfred's two emails also are in the
event semaphore code.
And the documentation for the mutex and event create functions has a
major error because it states that the returned handle can be passed to
the open
On Fri, 26 Oct 2012 10:05:40 -0400
Rick McGuire object.r...@gmail.com wrote:
On Fri, Oct 26, 2012 at 10:01 AM, David Ashley
w.david.ash...@gmail.comwrote:
I believe Manfred is correct on this one. I am not sure how this
ever worked. And the fix applies to both the Windows and *nix
David,
The change to SysOpenEventSem is NOT correct. The value being returned is
not an object pointer. This will result in a crash the first time the
garbage collector runs. The original return type is correct, the only
change should be which pointer value is getting returned.
Rick
Well something is not right because the semdata variable is NOT a
uintptr_t data type. It is a pointer to a structure.
David Ashley
On Fri, 2012-10-26 at 11:06 -0400, Rick McGuire wrote:
David,
The change to SysOpenEventSem is NOT correct. The value being
returned is not an object
On Fri, Oct 26, 2012 at 11:14 AM, David Ashley w.david.ash...@gmail.comwrote:
Well something is not right because the semdata variable is NOT a
uintptr_t data type. It is a pointer to a structure.
That is correct. A uintptr_t value is an integer value that is guaranteed
to be the same size
On Fri, 26 Oct 2012 10:03:52 -0500
David Ashley w.david.ash...@gmail.com 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
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.
The only thing sem_unlink actually does is prevent
On Fri, 26 Oct 2012 11:16:30 -0500
David Ashley w.david.ash...@gmail.com 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
On Fri, 26 Oct 2012 17:33:05 +0100
Mike Cowlishaw m...@speleotrove.com wrote:
Curious .. I use mutex in Rexx (mostly to protect .ini file updates
in Windows and Linux, mostly Windows) and have had occasional
failures that appeared to be due to some kind of corruption. Could
this problem
Curious .. I use mutex in Rexx (mostly to protect .ini file
updates in
Windows and Linux, mostly Windows) and have had occasional failures
that appeared to be due to some kind of corruption. Could this
problem be related ... i.e., mutexes not working as expected?
If you mean
On Fri, 26 Oct 2012 18:12:07 +0100
Mike Cowlishaw m...@speleotrove.com wrote:
Curious .. I use mutex in Rexx (mostly to protect .ini file
updates in
Windows and Linux, mostly Windows) and have had occasional
failures that appeared to be due to some kind of corruption.
Could
17 matches
Mail list logo
