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.

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!
  • Cool, it seems to work on FreeBSD.

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

    Thanks!!

    My pleasure. :)

    -Andrew
  • 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.
  • 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
  • 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