https://bz.apache.org/bugzilla/show_bug.cgi?id=62277
--- Comment #33 from Rainer Jung <rainer.j...@kippdata.de> ---
Hi Yann,
in addition to the file descriptor ulimit I also had to increase the number of
shared memory identifiers "project.max-shm-ids" from the default of 256 (I
chose 10000).
Running the tool with a fresh work firectory named "work" and "--path work" I
got
0 collision(s) for 3990/3990 files
BUT: using no "--path" and thus using /tmp I got:
shmget: File exists
0 collision(s) for 1425/3990 files
and the number 1425 varies by test run.
Underneath /tmp I always get no collisions but "shmget: File exists" using
default settings as well as with a custom sub directory. On other local or NFS
mounted directories, I do not get them. Even if I check for collisions directly
after the shmget error, I do not get such. But I had to adjust the
check_collisions argument from "i" to "i-1" (otherwise it segfaulted when
shmget threw an error).
Concerning "shmget: File exists" from the Solaris man page:
EEXIST A shared memory identifier exists for key
but both (shmflg&IPC_CREAT) and
(shmflg&IPC_EXCL) are true.
and looking at the ftok man page:
NOTES
Since the ftok() function returns a value based on the id
given and the file serial number of the file named by path
in a type that is no longer large enough to hold all file
serial numbers, it may return the same key for paths naming
different files on large filesystems.
... and ...
USAGE
...
Another way to compose keys is to include the project ID in
the most significant byte and to use the remaining portion
as a sequence number. There are many other ways to form
keys, but it is necessary for each system to define stan-
dards for forming them. If some standard is not adhered to,
it will be possible for unrelated processes to unintention-
ally interfere with each other's operation. It is still pos-
sible to interfere intentionally. Therefore, it is strongly
suggested that the most significant byte of a key in some
sense refer to a project so that keys do not conflict across
a given system.
I also compiled as a 64 bit binary but got the same results.
Here's an example for two identical keys generated by ftok:
ftok 81/3990 for /tmp/slotmem-shm-p98b37289_ir.shm and -544118222 is 838870549
ftok 168/3990 for /tmp/slotmem-shm-p5750b6d1_jra.shm and 1374409266 is
838870549
In sys/types.h there's a part
/*
* POSIX and XOPEN Declarations
*/
typedef int key_t; /* IPC key type */
Regards,
Rainer
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
