[Bug 684] New: Trunk fails to build on mac as pthread_mutex_timedlock() not available

Submitted by snrkiwi on Sat, 2009-07-18 16:45

RTT-dev

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684

Summary: Trunk fails to build on mac as
pthread_mutex_timedlock() not available
Product: RTT
Version: rtt-trunk
Platform: All
OS/Version: Mac OS X
Status: NEW
Severity: blocker
Priority: P3
Component: Operating System Abstraction - Portability
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

Unable to build RTT trunk as

------------------------------------------------------------------------
r30285 | psoetens | 2009-07-17 08:08:13 -0400 (Fri, 17 Jul 2009) | 3 lines
 
Added rtos_mutex_lock_until and rtos_mutex_rec_lock_until to fosi Adapted
gnulinux, lxrt and macosx.

requires pthread_mutex_timedlock() in src/os/macosx/fosi.h, which is not
available on Mac OS X (Leopard).

+    static inline int rtos_mutex_lock_until( rt_mutex_t* m, NANO_TIME
abs_time)
+    {
+        TIME_SPEC arg_time = ticks2timespec( abs_time );
+        return pthread_mutex_timedlock(m, &arg_time);
+    }
+
+    static inline int rtos_mutex_rec_lock_until( rt_mutex_t* m, NANO_TIME
abs_time)
+    {
+        TIME_SPEC arg_time = ticks2timespec( abs_time );
+        return pthread_mutex_timedlock(m, &arg_time);
+    }
+

Original culprit appears to be

From: Peter Soetens <peter@thesourceworks.com>
------------------------------------------------------------------------
r30286 | psoetens | 2009-07-17 08:08:16 -0400 (Fri, 17 Jul 2009) | 3 lines
 
Added MutexTimedLock class and Mutex::timedlock function.

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by peter on Mon, 2009-11-02 10:28.

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684

Peter Soetens <peter [..] ...> changed:

--- Comment #5 from Peter Soetens <peter [..] ...> 2009-10-27 12:38:09 ---
(In reply to comment #4)
> I need someone to validate if the commit:
>
> commit 773e30da280326264c43cf6179cd13fc769a5eb9
> Author: Peter Soetens <peter [..] ...>
> Date: Wed Jul 22 14:48:28 2009 +0200
>
> Fix bug #684: Trunk fails to build on mac as pthread_mutex_timedlock() not
> available.
> As discussed on the ML, allow to fallback on Boost.Thread using the
> ORO_OS_USE_BOOST_THREAD flag.
>
> fixes this bug. Please close this bug if so. It's r30387 on SVN trunk.

Since no-one's closing this and no-one's complaining, I'll close it.

Peter

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by peter on Wed, 2009-08-12 21:45.

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684

Peter Soetens <peter [..] ...> changed:

--- Comment #4 from Peter Soetens <peter [..] ...> 2009-08-12 23:41:07 ---
I need someone to validate if the commit:

commit 773e30da280326264c43cf6179cd13fc769a5eb9
Author: Peter Soetens <peter [..] ...>
Date: Wed Jul 22 14:48:28 2009 +0200

Fix bug #684: Trunk fails to build on mac as pthread_mutex_timedlock() not
available.
As discussed on the ML, allow to fallback on Boost.Thread using the
ORO_OS_USE_BOOST_THREAD flag.

fixes this bug. Please close this bug if so. It's r30387 on SVN trunk.

Peter

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by snrkiwi on Thu, 2009-08-13 02:05.

On Aug 12, 2009, at 17:41 , Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684
>
>
> Peter Soetens <peter [..] ...> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status Whiteboard| |This needs to be
> worked out
> | |before 1.10 can get
> out.
> Target Milestone|--- |1.10.0
> Status|NEW |ASSIGNED
>
>
>
>
> --- Comment #4 from Peter Soetens <peter [..] ...>
> 2009-08-12 23:41:07 ---
> I need someone to validate if the commit:
>
> commit 773e30da280326264c43cf6179cd13fc769a5eb9
> Author: Peter Soetens <peter [..] ...>
> Date: Wed Jul 22 14:48:28 2009 +0200
>
> Fix bug #684: Trunk fails to build on mac as
> pthread_mutex_timedlock() not
> available.
> As discussed on the ML, allow to fallback on Boost.Thread using the
> ORO_OS_USE_BOOST_THREAD flag.
>
> fixes this bug. Please close this bug if so. It's r30387 on SVN trunk.
>
> Peter

Ahhhh ... was this commit in git or svn? Can't find any changes on SVN
trunk right now ...

You're going to force me to learn git now ... aren't you ... ? :-)

Stephen

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by peter on Thu, 2009-08-13 07:05.

On Thu, Aug 13, 2009 at 02:52, S Roderick<kiwi [dot] net [..] ...> wrote:
> On Aug 12, 2009, at 17:41 , Peter Soetens wrote:
>
>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684
>>
>>
>> I need someone to validate if the commit:
>>
>> commit 773e30da280326264c43cf6179cd13fc769a5eb9
>> Author: Peter Soetens <peter [..] ...>
>> Date: Wed Jul 22 14:48:28 2009 +0200
>>
>> Fix bug #684: Trunk fails to build on mac as pthread_mutex_timedlock()
>> not
>> available.
>> As discussed on the ML, allow to fallback on Boost.Thread using the
>> ORO_OS_USE_BOOST_THREAD flag.
>>
>> fixes this bug. Please close this bug if so. It's r30387 on SVN trunk.
>>
>> Peter
>
> Ahhhh ... was this commit in git or svn? Can't find any changes on SVN trunk
> right now ...
>
> You're going to force me to learn git now ... aren't you ... ? :-)

You probably missed the part where I wrote "It's r30387 on SVN trunk." ?

Peter

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by snrkiwi on Thu, 2009-08-13 11:10.

On Aug 13, 2009, at 03:03 , Peter Soetens wrote:

> On Thu, Aug 13, 2009 at 02:52, S Roderick<kiwi [dot] net [..] ...> wrote:
>> On Aug 12, 2009, at 17:41 , Peter Soetens wrote:
>>
>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684
>>>
>>>
>>> I need someone to validate if the commit:
>>>
>>> commit 773e30da280326264c43cf6179cd13fc769a5eb9
>>> Author: Peter Soetens <peter [..] ...>
>>> Date: Wed Jul 22 14:48:28 2009 +0200
>>>
>>> Fix bug #684: Trunk fails to build on mac as
>>> pthread_mutex_timedlock()
>>> not
>>> available.
>>> As discussed on the ML, allow to fallback on Boost.Thread using
>>> the
>>> ORO_OS_USE_BOOST_THREAD flag.
>>>
>>> fixes this bug. Please close this bug if so. It's r30387 on SVN
>>> trunk.
>>>
>>> Peter
>>
>> Ahhhh ... was this commit in git or svn? Can't find any changes on
>> SVN trunk
>> right now ...
>>
>> You're going to force me to learn git now ... aren't you ... ? :-)
>
> You probably missed the part where I wrote "It's r30387 on SVN
> trunk." ?
>
> Peter

Mea culpa ... but ... :-(

Build log plus svn revision plus contents of orocos-rtt.cmake. I see
no changes in macosx/fosi.h that deal with boost threads instead of
pthread_mutex_timedlock(). The only changes appear to be in os/
Mutex.hpp.

What was your intent here?
Stephen

$ cmake ../../src/rtt/
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Orocos RTT version  (1.10.99)
Using custom defaults
-- CMAKE_VERSION: 2.6.3
-- Boost version: 1.38.0
-- Found the following Boost libraries:
--   program_options
--   thread
-- Could NOT find Xerces  (missing:  XERCES_C_LIBRARY  
XERCES_DEPDOM_LIBRARY XERCES_INCLUDE_DIR)
Orocos target is macosx
-- Detected gcc4: 4.0.1
 
-- Found Doxygen: /opt/local/bin/doxygen
-- Found Doxygen -- API documentation can be built
-- Looking for TAO with orbsvcs...
-- Found ACE: /opt/install/lib/libACE.dylib
-- TAO tao/corba.h found in /opt/install/include.
-- Assuming TAO >= 1.5 (based on location of Any.h)
-- TAO orbsvcs/CosNaming.idl found in /opt/install/include.
Looking for components: IDL;PortableServer;CosNaming;Messaging
-- tao_idl: /opt/install/bin/tao_idl
-- CORBA enabled: ACE;TAO;IDL;PortableServer;CosNaming;Messaging
Building CORBA Transport library.
-- Boost version: 1.38.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/sroderick/software/orocos- 
trunk/build/rtt
sroderick@serenity rtt $ make
Scanning dependencies of target orocos-rtt-dynamic_macosx
[  0%] Building CXX object src/CMakeFiles/orocos-rtt- 
dynamic_macosx.dir/ActionInterface.cpp.o
[  0%] Building CXX object src/CMakeFiles/orocos-rtt- 
dynamic_macosx.dir/Activity.cpp.o
/Users/sroderick/software/orocos-trunk/src/rtt/src/os/macosx/fosi.h:  
In function ‘int rtos_mutex_lock_until(rt_mutex_t*, NANO_TIME)’:
/Users/sroderick/software/orocos-trunk/src/rtt/src/os/macosx/fosi.h: 
260: error: ‘pthread_mutex_timedlock’ was not declared in this scope
/Users/sroderick/software/orocos-trunk/src/rtt/src/os/macosx/fosi.h:  
In function ‘int rtos_mutex_rec_lock_until(rt_mutex_t*, NANO_TIME)’:
/Users/sroderick/software/orocos-trunk/src/rtt/src/os/macosx/fosi.h: 
266: error: ‘pthread_mutex_timedlock’ was not declared in this scope
make[2]: *** [src/CMakeFiles/orocos-rtt-dynamic_macosx.dir/ 
Activity.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_macosx.dir/all] Error 2
make: *** [all] Error 2
sroderick@serenity rtt $ grep BOOST CMakeCache.txt
ORO_OS_USE_BOOST_THREAD:STRING=ON
 
sroderick@serenity rtt $ cat ../../src/rtt/orocos-rtt.cmake
MESSAGE("Using custom defaults")
 
SET(OROCOS_TARGET macosx CACHE STRING "" FORCE)
SET(CMAKE_INSTALL_PREFIX "/Users/sroderick/software/orocos-trunk/build/ 
rtt" CACHE PATH "" FORCE)
SET(ORO_OS_USE_BOOST_THREAD ON CACHE STRING "" FORCE)
 
OPTION(ENABLE_CORBA "" ON)
 
sroderick@serenity rtt $ svn info ../../src/rtt/
Path: ../../src/rtt
URL: http://svn.mech.kuleuven.be/repos/orocos/trunk/rtt
Repository Root: http://svn.mech.kuleuven.be/repos/orocos
Repository UUID: ce417995-dfc9-0310-95a0-acdaff106893
Revision: 30426
Node Kind: directory
Schedule: normal
Last Changed Author: psoetens
Last Changed Rev: 30423
Last Changed Date: 2009-08-11 08:38:26 -0400 (Tue, 11 Aug 2009)

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by peter on Thu, 2009-08-13 12:00.

On Thu, Aug 13, 2009 at 13:08, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> On Aug 13, 2009, at 03:03 , Peter Soetens wrote:
>
>> On Thu, Aug 13, 2009 at 02:52, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>
>>> On Aug 12, 2009, at 17:41 , Peter Soetens wrote:
>>>
>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684
>>>>
>>>>
>>>> I need someone to validate if the commit:
>>>>
>>>> commit 773e30da280326264c43cf6179cd13fc769a5eb9
>>>> Author: Peter Soetens <peter [..] ...>
>>>> Date: Wed Jul 22 14:48:28 2009 +0200
>>>>
>>>> Fix bug #684: Trunk fails to build on mac as pthread_mutex_timedlock()
>>>> not
>>>> available.
>>>> As discussed on the ML, allow to fallback on Boost.Thread using the
>>>> ORO_OS_USE_BOOST_THREAD flag.
>>>>
>>>> fixes this bug. Please close this bug if so. It's r30387 on SVN trunk.
>>>>
>>>> Peter
>>>
>>> Ahhhh ... was this commit in git or svn? Can't find any changes on SVN
>>> trunk
>>> right now ...
>>>
>>> You're going to force me to learn git now ... aren't you ... ? :-)
>>
>> You probably missed the part where I wrote "It's r30387 on SVN trunk." ?
>>
>> Peter
>
> Mea culpa ... but ... :-(
>
> Build log plus svn revision plus contents of orocos-rtt.cmake. I see no
> changes in macosx/fosi.h that deal with boost threads instead of
> pthread_mutex_timedlock(). The only changes appear to be in os/Mutex.hpp.
>
> What was your intent here?

The option is available to *all* platforms, not just macosx (hence
only Mutex.hpp).

You (I should have) just need to remove all *mutex* related fosi.h
functions in macosx...
Or even just the two offending function, they won't be used when the
flag is turned on.

Peter

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by snrkiwi on Thu, 2009-08-13 12:35.

On Aug 13, 2009, at 07:55 , Peter Soetens wrote:

> On Thu, Aug 13, 2009 at 13:08, Stephen Roderick<kiwi [dot] net [..] ...>
> wrote:
>> On Aug 13, 2009, at 03:03 , Peter Soetens wrote:
>>
>>> On Thu, Aug 13, 2009 at 02:52, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>>
>>>> On Aug 12, 2009, at 17:41 , Peter Soetens wrote:
>>>>
>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684
>>>>>
>>>>>
>>>>> I need someone to validate if the commit:
>>>>>
>>>>> commit 773e30da280326264c43cf6179cd13fc769a5eb9
>>>>> Author: Peter Soetens <peter [..] ...>
>>>>> Date: Wed Jul 22 14:48:28 2009 +0200
>>>>>
>>>>> Fix bug #684: Trunk fails to build on mac as
>>>>> pthread_mutex_timedlock()
>>>>> not
>>>>> available.
>>>>> As discussed on the ML, allow to fallback on Boost.Thread using
>>>>> theORO_OS_USE_BOOST_THREAD flag.
>>>>>
>>>>> fixes this bug. Please close this bug if so. It's r30387 on SVN
>>>>> trunk.
>>>>>
>>>>> Peter
>>>>
>>>> Ahhhh ... was this commit in git or svn? Can't find any changes
>>>> on SVN
>>>> trunk
>>>> right now ...
>>>>
>>>> You're going to force me to learn git now ... aren't you ... ? :-)
>>>
>>> You probably missed the part where I wrote "It's r30387 on SVN
>>> trunk." ?
>>>
>>> Peter
>>
>> Mea culpa ... but ... :-(
>>
>> Build log plus svn revision plus contents of orocos-rtt.cmake. I
>> see no
>> changes in macosx/fosi.h that deal with boost threads instead of
>> pthread_mutex_timedlock(). The only changes appear to be in os/
>> Mutex.hpp.
>>
>> What was your intent here?
>
> The option is available to *all* platforms, not just macosx (hence
> only Mutex.hpp).
>
> You (I should have) just need to remove all *mutex* related fosi.h
> functions in macosx...
> Or even just the two offending function, they won't be used when the
> flag is turned on.

That does fix it, but there are some other TAO issues (you know me,
non-standard install locations). I have a whole bunch of fixes for the
CORBA packages, I'll get back to you in the next couple of days ... I
will wait until we get a clean build before closing the ticket.

Also, if this is _required_ on macosx, shouldn't we just turn on
ORO_OS_USE_BOOST_THREAD automatically on that platform? It will just
cause user confusion later otherwise.

Stephen

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by peter on Sun, 2009-07-19 21:40.

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684

--- Comment #3 from Peter Soetens <peter [..] ...> 2009-07-19 23:37:07 ---
(In reply to comment #0)
> Unable to build RTT trunk as
>
>

> ------------------------------------------------------------------------
> r30285 | psoetens | 2009-07-17 08:08:13 -0400 (Fri, 17 Jul 2009) | 3 lines
> 
> Added rtos_mutex_lock_until and rtos_mutex_rec_lock_until to fosi Adapted
> gnulinux, lxrt and macosx.
> 
>

>
> requires pthread_mutex_timedlock() in src/os/macosx/fosi.h, which is not
> available on Mac OS X (Leopard).

I should have noted my references when I wrote I checked macosx... Boost has a
workaround in boost/threads/pthread/mutex.hpp.

The best solution would be to be able to rely on Boost completely in Mutex.hpp
and MutexRecursive.hpp and enable this for Mac-OS-X. (say
ORO_USE_BOOST_THREADS) The mapping looks a 1-to-1. We can then remove the mutex
code from macosx/fosi.h. In the long turn, the same (and more functions) can be
done for all targets supporting posix (or to say, supported by Boost).

Peter

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by snrkiwi on Mon, 2009-07-20 14:10.

On Jul 19, 2009, at 17:37 , Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684
>
> --- Comment #3 from Peter Soetens <peter [..] ...>
> 2009-07-19 23:37:07 ---
> (In reply to comment #0)
>> Unable to build RTT trunk as
>>
>>

>> ------------------------------------------------------------------------
>> r30285 | psoetens | 2009-07-17 08:08:13 -0400 (Fri, 17 Jul 2009) |  
>> 3 lines
>>
>> Added rtos_mutex_lock_until and rtos_mutex_rec_lock_until to fosi  
>> Adapted
>> gnulinux, lxrt and macosx.
>>
>>

>>
>> requires pthread_mutex_timedlock() in src/os/macosx/fosi.h, which
>> is not
>> available on Mac OS X (Leopard).
>
> I should have noted my references when I wrote I checked macosx...
> Boost has a
> workaround in boost/threads/pthread/mutex.hpp.
>
> The best solution would be to be able to rely on Boost completely in
> Mutex.hpp
> and MutexRecursive.hpp and enable this for Mac-OS-X. (say
> ORO_USE_BOOST_THREADS) The mapping looks a 1-to-1. We can then
> remove the mutex
> code from macosx/fosi.h. In the long turn, the same (and more
> functions) can be
> done for all targets supporting posix (or to say, supported by Boost).

The thing that I don't like about the boost threads library is that is
have undefined/unspecified behaviour for certain things, like waking
up multiple tasks locked on a just-unlocked mutex. Whether that really
bothers us is another story.

Looking through the most recent doc's for boost::threads, the actual
order of thread wakeup is not mentioned anywhere. Actually, the doc's
are a barren wasteland on semantics such as this (as opposed to
syntax). The boost 1.34 doc's do mention this problem, see http://www.boost.org/doc/libs/1_34_0/doc/html/thread/concepts.html
and search for section "Scheduling Policies".

YMMV
S

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by peter on Wed, 2009-07-22 10:45.

On Mon, Jul 20, 2009 at 15:04, S Roderick<kiwi [dot] net [..] ...> wrote:
>> I should have noted my references when I wrote I checked macosx... Boost
>> has a
>> workaround in boost/threads/pthread/mutex.hpp.
>>
>> The best solution would be to be able to rely on Boost completely in
>> Mutex.hpp
>> and MutexRecursive.hpp and enable this for Mac-OS-X. (say
>> ORO_USE_BOOST_THREADS) The mapping looks a 1-to-1. We can then remove the
>> mutex
>> code from macosx/fosi.h. In the long turn, the same (and more functions)
>> can be
>> done for all targets supporting posix (or to say, supported by Boost).
>
> The thing that I don't like about the boost threads library is that is have
> undefined/unspecified behaviour for certain things, like waking up multiple
> tasks locked on a just-unlocked mutex. Whether that really bothers us is
> another story.

It's the scheduler that decides, so how could boost specify that behaviour ?

>
> Looking through the most recent doc's for boost::threads, the actual order
> of thread wakeup is not mentioned anywhere. Actually, the doc's are a barren
> wasteland on semantics such as this (as opposed to syntax). The boost 1.34
> doc's do mention this problem, see
> http://www.boost.org/doc/libs/1_34_0/doc/html/thread/concepts.html and
> search for section "Scheduling Policies".

I'm more in favour of re-using boost then to copy/paste their solution
in our macos-x layer...

I'll take a go at the patch.

Peter

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by snrkiwi on Wed, 2009-07-22 11:50.

On Jul 22, 2009, at 06:41 , Peter Soetens wrote:

> On Mon, Jul 20, 2009 at 15:04, S Roderick<kiwi [dot] net [..] ...> wrote:
>>> I should have noted my references when I wrote I checked macosx...
>>> Boost
>>> has a
>>> workaround in boost/threads/pthread/mutex.hpp.
>>>
>>> The best solution would be to be able to rely on Boost completely in
>>> Mutex.hpp
>>> and MutexRecursive.hpp and enable this for Mac-OS-X. (say
>>> ORO_USE_BOOST_THREADS) The mapping looks a 1-to-1. We can then
>>> remove the
>>> mutex
>>> code from macosx/fosi.h. In the long turn, the same (and more
>>> functions)
>>> can be
>>> done for all targets supporting posix (or to say, supported by
>>> Boost).
>>
>> The thing that I don't like about the boost threads library is that
>> is have
>> undefined/unspecified behaviour for certain things, like waking up
>> multiple
>> tasks locked on a just-unlocked mutex. Whether that really bothers
>> us is
>> another story.
>
> It's the scheduler that decides, so how could boost specify that
> behaviour ?

Agreed. I think it may have simply been that they couldn't specify
consistent behaviour for all platforms, and so chose none.

>> Looking through the most recent doc's for boost::threads, the
>> actual order
>> of thread wakeup is not mentioned anywhere. Actually, the doc's are
>> a barren
>> wasteland on semantics such as this (as opposed to syntax). The
>> boost 1.34
>> doc's do mention this problem, see
>> http://www.boost.org/doc/libs/1_34_0/doc/html/thread/concepts.html
>> and
>> search for section "Scheduling Policies".
>
> I'm more in favour of re-using boost then to copy/paste their solution
> in our macos-x layer...

Agreed too.
S

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by peter on Wed, 2009-07-22 12:55.

On Wed, Jul 22, 2009 at 13:43, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> On Jul 22, 2009, at 06:41 , Peter Soetens wrote:
>
>> On Mon, Jul 20, 2009 at 15:04, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>>
>>>> I should have noted my references when I wrote I checked macosx... Boost
>>>> has a
>>>> workaround in boost/threads/pthread/mutex.hpp.
>>>>
>>>> The best solution would be to be able to rely on Boost completely in
>>>> Mutex.hpp
>>>> and MutexRecursive.hpp and enable this for Mac-OS-X. (say
>>>> ORO_USE_BOOST_THREADS) The mapping looks a 1-to-1. We can then remove
>>>> the
>>>> mutex
>>>> code from macosx/fosi.h. In the long turn, the same (and more functions)
>>>> can be
>>>> done for all targets supporting posix (or to say, supported by Boost).
>>>
>>> The thing that I don't like about the boost threads library is that is
>>> have
>>> undefined/unspecified behaviour for certain things, like waking up
>>> multiple
>>> tasks locked on a just-unlocked mutex. Whether that really bothers us is
>>> another story.
>>
>> It's the scheduler that decides, so how could boost specify that behaviour
>> ?
>
> Agreed. I think it may have simply been that they couldn't specify
> consistent behaviour for all platforms, and so chose none.
>
>>> Looking through the most recent doc's for boost::threads, the actual
>>> order
>>> of thread wakeup is not mentioned anywhere. Actually, the doc's are a
>>> barren
>>> wasteland on semantics such as this (as opposed to syntax). The boost
>>> 1.34
>>> doc's do mention this problem, see
>>> http://www.boost.org/doc/libs/1_34_0/doc/html/thread/concepts.html and
>>> search for section "Scheduling Policies".
>>
>> I'm more in favour of re-using boost then to copy/paste their solution
>> in our macos-x layer...

In attachment two patches: one for fixing the TAO_Messaging and the
other for adding the ORO_OS_USE_BOOST_THREAD cmake option. It's not
yet hard-linked to macos-x. You'll need to toggle the flag manually.
If it works for you, we can toggle it hard when the macos-x target is
selected.

Peter

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by peter on Sun, 2009-07-19 21:30.

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |peter [..] ...

--- Comment #2 from Peter Soetens <peter [..] ...> 2009-07-19 23:07:06 ---
(In reply to comment #1)
> Also, the "TAO_Messaging" component required by config/check_depend.cmake (line
> 238) does not exist in a default install (from source) of ACE/TAO v5.6.5 on the
> Mac. Is this something that Orocos requires?

Not hard. We could make it a check in cmake and only enable connection timeouts
if its available.

Peter

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by snrkiwi on Mon, 2009-07-20 13:20.

On Jul 19, 2009, at 17:07 , Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684
>
>
> Peter Soetens <peter [..] ...> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |
> peter [..] ...
>
>
>
>
> --- Comment #2 from Peter Soetens <peter [..] ...>
> 2009-07-19 23:07:06 ---
> (In reply to comment #1)
>> Also, the "TAO_Messaging" component required by config/
>> check_depend.cmake (line
>> 238) does not exist in a default install (from source) of ACE/TAO
>> v5.6.5 on the
>> Mac. Is this something that Orocos requires?
>
> Not hard. We could make it a check in cmake and only enable
> connection timeouts
> if its available.

Works for me.

Where are connection timeouts used in Orocos?
S

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by snrkiwi on Mon, 2009-07-20 13:15.

On Jul 19, 2009, at 17:07 , Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684
>
>
> Peter Soetens <peter [..] ...> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |peter [..] ...
>
>
>
>
> --- Comment #2 from Peter Soetens <peter [..] ...>
> 2009-07-19 23:07:06 ---
> (In reply to comment #1)
>> Also, the "TAO_Messaging" component required by config/
>> check_depend.cmake (line
>> 238) does not exist in a default install (from source) of ACE/TAO
>> v5.6.5 on the
>> Mac. Is this something that Orocos requires?
>
> Not hard. We could make it a check in cmake and only enable
> connection timeouts
> if its available.

Works for me.

Where are connection timeouts used in Orocos?
S

[Bug 684] Trunk fails to build on mac as pthread_mutex_timedlock

Submitted by peter on Wed, 2009-07-22 10:40.

On Mon, Jul 20, 2009 at 15:05, S Roderick<kiwi [dot] net [..] ...> wrote:
> On Jul 19, 2009, at 17:07 , Peter Soetens wrote:
>
>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=684
>>
>>
>> Peter Soetens <peter [..] ...> changed:
>>
>> What |Removed |Added
>>
>> ----------------------------------------------------------------------------
>> CC| |peter [..] ...
>>
>>
>>
>>
>> --- Comment #2 from Peter Soetens <peter [..] ...> 2009-07-19
>> 23:07:06 ---
>> (In reply to comment #1)
>>>
>>> Also, the "TAO_Messaging" component required by config/check_depend.cmake
>>> (line
>>> 238) does not exist in a default install (from source) of ACE/TAO v5.6.5
>>> on the
>>> Mac. Is this something that Orocos requires?
>>
>> Not hard. We could make it a check in cmake and only enable connection
>> timeouts
>> if its available.
>
> Works for me.
>
> Where are connection timeouts used in Orocos?

The ORB is configured to bail out if responses take too long. You can
set the global timeout value in the ApplicationSetup::InitOrb
function.
We already check for 'CORBA_IS_TAO' we could also check for messaging.

Peter