darwin missing clock_gettime (causing problems in shmem)
I was trying to use the shmem library on darwin and ran into errors because darwin does not have a clock_gettime function. I believe there needs to be something like a BOOST_HAS_CLOCK_GETTIME in config.hpp -- either there, or in shmem. Then the following patch for shmem would probably be appropriate: --- shmemlib-0-orig/boost/shmem/sync/xtime.hpp 2005-12-30 19:32:02.000000000 +0000 +++ shmemlib-0/boost/shmem/sync/xtime.hpp 2006-04-11 22:24:09.000000000 +0000 @@ -102,12 +102,19 @@ #else - + + #if defined BOOST_HAS_CLOCK_GETTIME timespec ts; clock_gettime(CLOCK_REALTIME, &ts); xtp->sec = ts.tv_sec; xtp->nsec = ts.tv_nsec; - return clock_type; + #else + struct timeval tv; + if (gettimeofday (&tv, 0) == 0) { + xtp->sec = tv.tv_sec; + xtp->nsec = tv.tv_usec*1000; + } + #endif #endif return clock_type; With this patch, I am able to get the examples in shmem to build. Unfortunately, it then fails in boost::shmem::detail::mutexattr_wrapper::mutexattr_wrapper because pthread_mutexattr_init fails. I can go into more info about the problems with shmem on darwin if this is useful to anyone. I realize this may be the wrong list for this post since shmem is still in 0.9 development, so please point me in the right direction if so. -Ian Fasel
Hi Ian, Thanks for pointing out this. In the future, Shmem is becoming Interprocess so I plan to use Boost.Date_Time instead of my own time functions.
With this patch, I am able to get the examples in shmem to build. Unfortunately, it then fails in boost::shmem::detail::mutexattr_wrapper::mutexattr_wrapper because pthread_mutexattr_init fails.
That might suggest that your darwin version does not support process shared mutexes. I'm sorry I don't check that explicitly in my config headers (I'm lost in all those POSIX option checkings). Maybe you need to update your c library (darwin uses glibc or similar?) to get both gettime and process shared mutexes. I will try to implement some basic tests for future bugfix Shmem versions. Regards, Ion
Hi Ion, This thread from Feb 2004 may be helpful: http://lists.apple.com/archives/Darwin-development/2004/Feb/ msg00146.html "Darwin's pthreads implementation does not support the optional "Thread Process-Shared Synchronization" functionality, so calling pthread_mutexattr_setpshared() with the PTHREAD_PROCESS_SHARED attribute will return EINVAL." Darwin is the BSD-ish underbelly of Mac OS X, so it's not glibc but Apple supplied. I'm using Mac OS X version 10.4.5, so this is the most up to date darwin. -Ian On Apr 13, 2006, at 4:34 AM, Ion Gaztañaga wrote:
Hi Ian,
Thanks for pointing out this. In the future, Shmem is becoming Interprocess so I plan to use Boost.Date_Time instead of my own time functions.
With this patch, I am able to get the examples in shmem to build. Unfortunately, it then fails in boost::shmem::detail::mutexattr_wrapper::mutexattr_wrapper because pthread_mutexattr_init fails.
That might suggest that your darwin version does not support process shared mutexes. I'm sorry I don't check that explicitly in my config headers (I'm lost in all those POSIX option checkings).
Maybe you need to update your c library (darwin uses glibc or similar?) to get both gettime and process shared mutexes. I will try to implement some basic tests for future bugfix Shmem versions.
Regards,
Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
This thread from Feb 2004 may be helpful: http://lists.apple.com/archives/Darwin-development/2004/Feb/ msg00146.html "Darwin's pthreads implementation does not support the optional "Thread Process-Shared Synchronization" functionality, so calling pthread_mutexattr_setpshared() with the PTHREAD_PROCESS_SHARED attribute will return EINVAL."
Darwin is the BSD-ish underbelly of Mac OS X, so it's not glibc but Apple supplied. I'm using Mac OS X version 10.4.5, so this is the most up to date darwin.
That's bad news, since all Shmem/Interprocess POSIX synchronization is based on that. In windows I try to emulate it with spins and waits but that's really a pain because you don't get mutex benefits like priority inversion. I'm afraid you won't be able to use it until I implement those missing functions for POSIX systems using the same rude mechanism. But I don't know how much time I need to do that, since those atomic functions would be compiler/platform dependent. Maybe some Boost libraries (like smart_ptr) provide some portable atomic operations. I'm afraid I won't have time soon to do this, since my priority is to write the fist Interprocess version, but I will try to look at this. Regards, Ion
Ion Gaztañaga <igaztanaga@gmail.com> writes:
That's bad news, since all Shmem/Interprocess POSIX synchronization is based on that. In windows I try to emulate it with spins and waits but that's really a pain because you don't get mutex benefits like priority inversion.
I don't know the details of what you're trying to do, but on Windows, native synchronization objects can be shared between processes if you name them --- if any process then requests the object with the same name, they get the same mutex/semaphore/event. HTH, Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
participants (3)
-
Anthony Williams -
Ian Fasel -
Ion Gaztañaga