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

Reply via email to