portability problems with RecMutex ctor

[marlowa]

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.

[rodrigc]

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!

[rodrigc]

Cool, it seems to work on FreeBSD.

Thanks!!

[marlowa]

Originally posted by rodrigc
Cool, it seems to work on FreeBSD.

Thanks!!

My pleasure.

-Andrew

[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.

[marlowa]

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?

-Andrew

[marc]

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,
Marc