Thanks, Roel. That works a treat. Much better than rewriting the property code.
I've submitted the update as revision 1656. -----Original Message----- From: Roel van de Kraats [mailto:r...@advancedcargo.eu] Sent: 23 December 2010 14:15 To: Morrell Richard (external) Cc: 'John Calcote'; openslp-devel@lists.sourceforge.net Subject: Re: [Openslp-devel] Support for older platforms is broken Hi Richard, Recursive mutexes are available on most Linux systems for ages, so that should not cause a problem by itself. However, the pthread_mutexattr_settype() function (as used in slp_thread.c) is relatively young. In the software I work on, I've used a construction like this: #ifdef __USE_UNIX98 pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); #else pthread_mutexattr_setkind_np(&attr, PTHREAD_MUTEX_RECURSIVE_NP); #endif Perhaps this could work for you as well. BR, Roel On 12/23/2010 01:17 PM, Morrell Richard (external) wrote: > Hi John, > > I have a problem with building the latest version of the OpenSLP source > (revision 1655). > Copied to the mailing list so that developers are aware of the issue. > > We support OpenSLP internally on a number of platforms, some of which are > quite old (RedHat 4 Update 4, for example). The last version we took was > revision 1629, which built ok on the older platforms. > > Some of the changes since revision 1629 mean that building for the older > platforms now don't work. > > I did have a problem with AC_USE_SYSTEM_EXTENSIONS even on a relatively > recent Redhat 5 update 4 platform, as it has an earlier version of autoconf > (2.59) that doesn't support it (2.61 or later is required). Policy is to > use the versions that come with the platform, rather than upgrading, so I > worked around that by removing the AC_USE_SYSTEM_EXTENSIONS and re-instating > the __USE_UNIX98 setting in a patch. > > However, on RH4u4, the headers seem to be broken, such that enabling the > __USE_UNIX98 setting causes the build to fail (type pthread_rwlockattr_t is > not defined). > > The change went in to support recursive mutexes for the change to > slp_property.c to protect the properties re-init operation. It looks to me > as though the code could easily be rewritten to avoid the need for recursive > mutexes (remove locking from SLPPropertyCleanup, and add locking around the > calls to it). I have reviewed the changes from 1629 to 1655, and can find > no other changes to the use of locking. > > Are you aware of any issues other than the property re-init issue that > require the use of recursive mutexes ? > Is the use of AC_USE_SYSTEM EXTENSIONS required for anything other than > recursive mutexes ? > > If your answer to both the above questions is no, then I propose to revert > the changes you made in revisions 1637& 1639, and rewrite the property code > as indicated above, unless you have any objection. If you need > AC_USE_SYSTEM_EXTENSIONS for anything else, then I can work round that with > a patch (but I'd still like to remove recursive mutexes). > > Thanks, > > Richard Morrell > > This email, including any attachment, is a confidential communication > intended solely for the use of the individual or entity to whom it is > addressed. It contains information which is private and may be proprietary > or covered by legal professional privilege. If you have received this email > in error, please notify the sender upon receipt, and immediately delete it > from your system. > > Anything contained in this email that is not connected with the businesses > of this company is neither endorsed by nor is the liability of this company. > > Whilst we have taken reasonable precautions to ensure that any attachment to > this email has been swept for viruses, we cannot accept liability for any > damage sustained as a result of software viruses, and would advise that you > carry out your own virus checks before opening any attachment. > > > ---------------------------------------------------------------------------- -- > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Openslp-devel mailing list > Openslp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openslp-devel This email, including any attachment, is a confidential communication intended solely for the use of the individual or entity to whom it is addressed. It contains information which is private and may be proprietary or covered by legal professional privilege. If you have received this email in error, please notify the sender upon receipt, and immediately delete it from your system. Anything contained in this email that is not connected with the businesses of this company is neither endorsed by nor is the liability of this company. Whilst we have taken reasonable precautions to ensure that any attachment to this email has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Openslp-devel mailing list Openslp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-devel
