Re: [boost] [interprocess] HP-UX_ia64_gcc test failingduetopermissions
Boris Gubenko wrote:
You might want to reconsider how you create name argument for shm_open() function, at least on the platforms with filesystem-based implementation. In your example, the name begins with a slash and Interprocess library passes it to shm_open() untouched. But prepending the slash makes even "innocent" call like
shared_memory_object(create_only, "foo", read_write);
to fail. Perhaps, you can use name transformation algorithm which is currently used on the platforms where BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS macro is not defined on the platforms where this macro is defined as well. Just a thought.
According to the opengroup specification: http://www.opengroup.org/onlinepubs/007908799/xsh/shm_open.html The name argument conforms to the construction rules for a pathname. If name begins with the slash character, then processes calling shm_open() with the same value of name refer to the same shared memory object, as long as that name has not been removed. If name does not begin with the slash character, the effect is implementation-dependent. The interpretation of slash characters other than the leading slash character in name is implementation-dependent. So: -> If leading slash is not used, two processes might not access the same memory. -> If there are more slashes than the leading one, both processes refer the same shared memory but that name is not portable accross OSs. -> The only portable (between OSs) name is a name that only has a leading slash. In all POSIX books the recommended name format is "/name", (in fact, some systems don't accept a name without the leading slash). In Linux /name leading to a shared memory created in /dev/shm/name. Then I have two options: -> Transform internally the name for HP-UX to a directory where everyone can create shared memory. What should I choose? /tmp? -> Change names used in tests for HP-UX for something that works. It's a shame that there is no portable shared memory name for every system ;-), because many pages, like these: http://www.tin.org/bin/man.cgi?section=3&topic=shm_open http://linux.die.net/man/3/shm_open or some POSIX books say: "For portable use, name should have an initial slash (/) and contain no embedded slashes." I wasn't expecting permission problems, though ;-) Could you tell me a shared memory name that a user could use successfully in HP-UX? Thanks for your quick reply, it's been really helpful. Ion
Ion Gaztanaga wrote:
I wasn't expecting permission problems, though ;-) Could you tell me a shared memory name that a user could use successfully in HP-UX?
It is not just HP-UX. You would've had the same problem on Tru64 or VMS if the codepath that is taken on HP-UX was executed on these platforms -- see below. [ As a side remark: your check for whether the platform supports shared memory objects assumes that this functionality is available only if the macro _POSIX_SHARED_MEMORY_OBJECTS is defined with a value greater than zero. While this is correct assumption for X/Open Issue 6: The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, it is not a correct assumption for X/Open Issue 5: The Single UNIX Specification, Version 2, also known as UNIX 98. In UNIX 98, the macro can be defined with any value -- see <http://www.opengroup.org/onlinepubs/007908799/xsh/unistd.h.html> As I said in the previous mail, Tru64 defines _POSIX_SHARED_MEMORY_OBJECTS as an empty string and your check for shared memory objects availability fails on this platform, which is good in a sense :-) ] To answer your question, I think, that prepending "/tmp/boost_interprocess/" to the name is a good solution. You already do it on platforms which fail your shared memory objects availability check. Thanks, Boris HP-UX ----- bash-2.03$ cc -V cc: HP C/aC++ B3910B A.06.14 [Feb 22 2007] bash-2.03$ cc x.c && a.out shm_open: Permission denied bash-2.03$ Tru64 ----- cxxosf.zko.hp.com> cc -V Compaq C V6.5-207 (dtk) on Compaq Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver V6.5-207 (dtk) (dtk) cc Driver cxxosf.zko.hp.com> cc x.c -lrt && a.out shm_open: Permission denied cxxosf.zko.hp.com> VMS --- ICXXC::_1> cc/ver HP C V7.3-018 on OpenVMS IA64 XBPK-O3N ICXXC::_1> define DECC$POSIX_COMPLIANT_PATHNAMES 1 ICXXC::_1> pipe cc x.c ; link x.obj ; run x.exe shm_open: permission denied ICXXC::_1> x.c --- #include <sys/mman.h> #include <fcntl.h> #include <stdio.h> #include <sys/stat.h> int main() { int fd; char *name = "/shm_name"; int oflag = O_RDWR | O_CREAT | O_EXCL; fd = shm_open(name, oflag, S_IRWXO | S_IRWXG | S_IRWXU); if ( fd == -1 ) perror("shm_open"); else { puts("success"); shm_unlink(name); } }
Boris Gubenko wrote:
Ion Gaztanaga wrote:
I wasn't expecting permission problems, though ;-) Could you tell me a shared memory name that a user could use successfully in HP-UX?
It is not just HP-UX. You would've had the same problem on Tru64 or VMS if the codepath that is taken on HP-UX was executed on these platforms -- see below.
Ok, I see. Detecting POSIX conformance is really a nightmare ;-) I think I should just check for _POSIX_SHARED_MEMORY_OBJECTS, because I don't want to miss native shared memory for systems that support it. I suppose I have the same problem for other posix features like _POSIX_THREAD_PROCESS_SHARED. So if I understand it correctly, checking only for the existence of option macros should be enough if I want to support SUSV2 systems, right?
To answer your question, I think, that prepending "/tmp/boost_interprocess/" to the name is a good solution. You already do it on platforms which fail your shared memory objects availability check.
Ok. If POSIX_SHARED_MEMORY_OBJECTS is defined, I will add a prefix to the shared memory name on HP-UX, Tru64, VMS and other future systems that have filesystem based shared memory. Thanks again, Ion
Ion Gaztanaga wrote:
Ok, I see. Detecting POSIX conformance is really a nightmare ;-) I think I should just check for _POSIX_SHARED_MEMORY_OBJECTS, because I don't want to miss native shared memory for systems that support it.
As far as I can see, Interprocess library uses the following _POSIX_* feature test macros: _POSIX_BARRIERS _POSIX_SEMAPHORES _POSIX_SHARED_MEMORY_OBJECTS _POSIX_THREAD_PROCESS_SHARED _POSIX_TIMEOUTS In theory, a check for these macros should be accompanied by the check of the value of _XOPEN_SOURCE feature test macro because different releases of X/Open Specs define these _POSIX_* feature test macros differently. Using _POSIX_SHARED_MEMORY_OBJECTS as an example, I'd suggest the following check: #if defined(_POSIX_SHARED_MEMORY_OBJECTS) # if !((_XOPEN_SOURCE >= 600) && (_POSIX_SHARED_MEMORY_OBJECTS - 0 <= 0)) # define BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS # endif #endif I verified that the check above works in a default compilation on Linux, Tru64 and HP-UX, i.e. BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS macro gets defined. VMS supports shared memory objects but it does not define _POSIX_SHARED_MEMORY_OBJECTS macro, so you can define BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS on VMS as the following (70200000 is the first version of libc on VMS having shm_*() functions): #if defined(__vms) # if __CRTL_VER >= 70200000 # define BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS # endif #endif Currently, VMS does not support other _POSIX_* features used by the Interprocess library, so, BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS should be the only macro defined on this platform.
I suppose I have the same problem for other posix features like _POSIX_THREAD_PROCESS_SHARED. So if I understand it correctly, checking only for the existence of option macros should be enough if I want to support SUSV2 systems, right?
Right, but, I think, you also want to support XPG6 systems where the feature test macro can be defined with a value of -1 or 0. The check above takes it into account. Thanks, Boris
Boris Gubenko escribió:
In theory, a check for these macros should be accompanied by the check of the value of _XOPEN_SOURCE feature test macro because different releases of X/Open Specs define these _POSIX_* feature test macros differently. Using _POSIX_SHARED_MEMORY_OBJECTS as an example, I'd suggest the following check:
#if defined(_POSIX_SHARED_MEMORY_OBJECTS) # if !((_XOPEN_SOURCE >= 600) && (_POSIX_SHARED_MEMORY_OBJECTS - 0 <= 0)) # define BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS # endif #endif
Ok. Thanks for the info.
VMS supports shared memory objects but it does not define _POSIX_SHARED_MEMORY_OBJECTS macro, so you can define BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS on VMS as the following (70200000 is the first version of libc on VMS having shm_*() functions):
#if defined(__vms) # if __CRTL_VER >= 70200000 # define BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS # endif #endif
Ok. Thanks again! Ion
participants (2)
-
Boris Gubenko -
Ion Gaztañaga