Archived
This forum has been archived. Please start a new discussion on GitHub.
portability problems with RecMutex ctor
The RecMutex ctor has a non-std way of initialising the mutex attributes. It uses PTHREAD_MUTEX_RECURSIVE_NP instead of PTHREAD_MUTEX_RECURSIVE. This stops it compiling on Solaris. There is also a more std way to initalise the mutex attributes. The fixed code is:
IceUtil::RecMutex::RecMutex() :
_count(0)
{
pthread_mutexattr_t attr;
int rc = pthread_mutexattr_init(&attr);
if(rc != 0)
{
throw ThreadSyscallException(__FILE__, __LINE__);
}
rc = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
if(rc != 0)
{
throw ThreadSyscallException(__FILE__, __LINE__);
}
rc = pthread_mutex_init(&_mutex, &attr);
if(rc != 0)
{
throw ThreadSyscallException(__FILE__, __LINE__);
}
}
Regards,
Andrew M.
IceUtil::RecMutex::RecMutex() :
_count(0)
{
pthread_mutexattr_t attr;
int rc = pthread_mutexattr_init(&attr);
if(rc != 0)
{
throw ThreadSyscallException(__FILE__, __LINE__);
}
rc = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
if(rc != 0)
{
throw ThreadSyscallException(__FILE__, __LINE__);
}
rc = pthread_mutex_init(&_mutex, &attr);
if(rc != 0)
{
throw ThreadSyscallException(__FILE__, __LINE__);
}
}
Regards,
Andrew M.
0
Comments
-
Indeed you are correct!!
In fact, did you know that "_NP" in PTHREAD_MUTEX_RECURSIVE_NP
stands for "Not Portable"!
I'm going to try your patch on FreeBSD.
Thanks!0 -
Cool, it seems to work on FreeBSD.
Thanks!!0 -
Originally posted by rodrigc
Cool, it seems to work on FreeBSD.
Thanks!!
My pleasure.
-Andrew0 -
I changed the code so that PTHREAD_MUTEX_RECUSRIVE_NP will only be used if __linux__ is defined. Otherwise PTHREAD_MUTEX_RECURSIVE is used.
This fix will be in Ice-1.0.1.0 -
Originally posted by marc
I changed the code so that PTHREAD_MUTEX_RECUSRIVE_NP will only be used if __linux__ is defined. Otherwise PTHREAD_MUTEX_RECURSIVE is used.
This fix will be in Ice-1.0.1.
Unfortunately more is required than just a change to the macro name. The initialisation fails to compile on Solaris when all that is changed is the macro name. I strongly recommend that the POSIX-compliant way be used as given in a previous post. Is there any reason why it can't?
-Andrew0 -
Originally posted by marlowa
Unfortunately more is required than just a change to the macro name. The initialisation fails to compile on Solaris when all that is changed is the macro name. I strongly recommend that the POSIX-compliant way be used as given in a previous post. Is there any reason why it can't?
-Andrew
No, there is no reason. I just modified the code as you suggested.
Thanks,
Marc0