Good enough for me. :) John
On 12/23/2010 08:56 AM, Morrell Richard (external) wrote: > 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 ------------------------------------------------------------------------------ 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