Ok, so the rewrite's not quite as simple as that, but it's still straightforward - create non-mutexed functions for SLPPropertySet, SLPPropertyAsBoolean, and SLPPropertyAsInteger, and call them in InitializeMTUValue, ReadPropertyFile, and SetDefaultValues, as we know the mutex has already been acquired.
-----Original Message----- From: Morrell Richard (external) [mailto:richard.morr...@uk.thalesgroup.com] Sent: 23 December 2010 12:17 To: 'John Calcote' Cc: openslp-devel@lists.sourceforge.net Subject: [Openslp-devel] Support for older platforms is broken 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
