Hi,
>>I don't know why the link doesn't work. From my site it works
>What was displayed worked, "http:". But if you clicked on the link, "wlmailhtml:" didn't.
I edited my original message once again.
Added:
See http://groups.google.com/group/comp.unix.programme?r/browse_frm/thread/018671b4d364409f
>>Of course. My typo. So, can key2 differ from key1?
>(You can go back and edit it.)
Thanks. Edited.
>Yes, I explained how. If over NFS and the file gets unmounted, you get a different st_dev.
>>changing st_dev caused changing key returned by ftok(). We want to avoid that.
>It doesn't look like you can unless you keep it open. It seems they need to beef up the WARNINGS section.
They must beef up the WARNINGS section. But actually it doesn't help.
Currently it seems to there be a bug in design of ftok().
key = ftok("Name1", 'A').
File "Name1" is existing an accessible and never deleted.
Of course, an user expects to get the same key in all calls of ftok(), at least, between reboots.
--------------------------------------------
HP-UX hpx418 B.11.23 U ia64 1139467043 unlimited-user license
> man ftok
ftok(3C) ftok(3C)
NAME
ftok() - create interprocess communication identifier
SYNOPSIS
#include <sys/ipc.h>
key_t ftok(const char *path, int id);
DESCRIPTION
All interprocess communication facilities require the user to supply a
key to be used by the msgget(), semget(), and shmget() system calls to
obtain interprocess communication identifiers (see msgget(2),
semget(2), and shmget(2)).
ftok() returns a key based on path and id that is usable in subsequent
msgget(), semget(), and shmget() system calls.
The parameters for the ftok() function are as follows:
path must be the path name of an existing file
that is accessible to the process.
id is a character that uniquely identifies a
project. This means that only the low order
8-bits of id are significant. Note that
ftok() returns the same key for linked files
when called with the same id and that it
returns different keys when called with the
same file name but different ids.
RETURN VALUE
ftok() returns (key_t)-1 if path does not exist or if it is not
accessible to the process.
EXAMPLES
The following call to ftok() returns a key associated with the file
myfile and id A:
key_t mykey;
mykey = ftok ("myfile", 'A');
WARNINGS
If the file whose path is passed to ftok() is removed when keys still
refer to the file, future calls to ftok() with the same path and id
will return an error. If the same file is recreated, ftok() is likely
to return a different key than it did the original time it was called.
SEE ALSO
intro(2), msgget(2), semget(2), shmget(2), thread_safety(5).
Hewlett-Packard Company - 1 - HP-UX 11i Version 2: August 2003
--------------------------------------------
That man is very "smart":
1. No info about (the same or not the same) key returned by ftok() with file that wasn't deleted.
2. No info about reboots
3. No info about mounting/unmounting.
>>What should be compiled? It seems that I don't understand that issue.
>I was saying there are several applications that also depend on stat(2) and st_dev.
>1) Linker to check dependent shlibs, fails if it takes a long time.
>2) dld.so to check if already loaded. This works, since files are mmap(2).
>3) aCC compiler driver. This works since stdout/stderr is still open. And wouldn't matter anyway. ;-)
....
I didn't understand how we can use it.
We have situation like this.
int main()
{
key = ftok("Name1", 'A');
id = shmget (key, ..., ...);
// If Shm segment with key is not existing we create, it.
// Otherwise we must work with existing Shm segment
// So, if while run-1 we get key1, while run-2 we get key2
// and key2 != key1
// then
// 1) data from Shm segment key1 will be lost.
// 2) we never can get key1 via ftok()
shmat(...);
...
shmdt();
...
}
Let myexe is executable of that main()
Now, we work as it follows:
====================================
create file "Name1"
...
reboot-1
myexe
...
myexe
...
myexe
...
reboot-2
myexe
...
myexe
...
myexe
...
reboot-3
====================================
OK, keys in intervals (reboot-1, reboot-2) and (reboot-2, reboot-3) may be different. No problem.
How can we use linker options and aCC compiler driver to guarantee the same key within each interval in our situation?
We have myexe + libraries already created.
Dennis, thank you very much.
