I'm sorry I haven't been very responsive. Richard, your approach is the best really. The reentrant mutex solution was my bright idea to get it done quickly, but not reacquiring a mutex you should know you already have is the better design (usually in every case).
John On 12/23/2010 06:47 AM, Morrell Richard (external) wrote: > 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
