Penguin

Differences between current version and previous revision of msgget(2).

Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History

Newer page: version 2 Last edited on Saturday, March 15, 2003 1:14:14 am by PerryLorier
Older page: version 1 Last edited on Tuesday, June 4, 2002 12:23:43 am by perry Revert
@@ -1,179 +1,67 @@
-MSGGET  
-!!!MSGGET  
-NAME  
-SYNOPSIS  
-DESCRIPTION  
-RETURN VALUE  
-ERRORS  
-NOTES  
-BUGS  
-CONFORMING TO  
-SEE ALSO  
-----  
 !!NAME 
+msgget - get a message queue identifier  
  
-  
-msgget - get a message queue identifier  
 !!SYNOPSIS 
+ __#include <sys/types.h>__  
+ __#include <sys/ipc.h>__  
+ __#include <sys/msg.h>__  
+ __int msgget ( key_t__ ''key''__, int__ ''msgflg'' __)__  
  
-  
-__# include  
-____int msgget ( key_t__ ''key''__, int__ ''msgflg'' __)__  
 !!DESCRIPTION 
+The function returns the message queue identifier associated to the value of the ''key'' argument. A new message queue is created if ''key'' has value __IPC_PRIVATE__ or  
+''key'' isn't __IPC_PRIVATE__, no existing message queue is associated to ''key'', and __IPC_CREAT__ is asserted in ''msgflg'' (i.e.  
+''msgflg''____''IPC_CREAT'' is nonzero). The presence in ''msgflg'' of the fields __IPC_CREAT__ and __IPC_EXCL__ plays the same role, with respect to the  
+existence of the message queue, as the presence of __O_CREAT__ and __O_EXCL__ in the mode argument of the open(2) system call: i.e. the __msgget__ function  
+fails if ''msgflg'' asserts both __IPC_CREAT__ and __IPC_EXCL__ and a message queue already exists for ''key''.  
  
+Upon creation, the lower 9 bits of the argument ''msgflg'' define the access permissions of the message queue. These permission bits have the same format and semantics as the access permissions parameter in open(2) or creat(2) system calls. (The execute permissions are not used.)  
  
-The function returns the message queue identifier associated  
-to the value of the ''key'' argument. A new message queue  
-is created if ''key'' has value __IPC_PRIVATE__ or  
-''key'' isn't __IPC_PRIVATE__ , no existing message  
-queue is associated to ''key'' , and __IPC_CREAT__ is  
-asserted in ''msgflg'' (i.e.  
-''msgflg''____''IPC_CREAT'' is nonzero). The  
-presence in ''msgflg'' of the fields __IPC_CREAT__ and  
-__IPC_EXCL__ plays the same role, with respect to the  
-existence of the message queue, as the presence of  
- __O _CREAT __ and __O_EXCL__ in the mode argument of the  
-open(2) system call : i.e. the __msgget__ function  
-fails if ''msgflg'' asserts both __IPC_CREAT__ and  
-__IPC_EXCL__ and a message queue already exists for  
-''key''.  
+Furthermore , while creating , the system call initializes the system message queue data structure __msqid _ds __ as follows
  
+__msg_perm.cuid__ and __msg_perm.uid__ are set to the effective user-ID of the calling process.  
  
-Upon creation, the lower 9 bits of the argument  
-''msgflg'' define the access permissions of the message  
-queue . These permission bits have the same format and  
-semantics as the access permissions parameter in  
-open(2) or creat(2) system calls . (The execute  
-permissions are not used .)  
+__msg_perm .cgid__ and __msg_perm .gid__ are set to the effective group-ID of the calling process
  
+The lowest order 9 bits of __msg_perm.mode__ are set to the lowest order 9 bit of ''msgflg''.  
  
-Furthermore, while creating, the system call initializes the  
-system message queue data structure __msqid_ds__ as  
-follows:  
-  
-  
-__msg_perm.cuid__ and __msg_perm.uid__ are set to the  
-effective user-ID of the calling process.  
-  
-  
-__msg_perm.cgid__ and __msg_perm.gid__ are set to the  
-effective group-ID of the calling process.  
-  
-  
-The lowest order 9 bits of __msg_perm.mode__ are set to  
-the lowest order 9 bit of ''msgflg''.  
-  
-  
- __msg_qnum__, __msg_lspid__, __msg_lrpid__,  
- __msg_stime__ and __msg_rtime__ are set to  
- .  
-  
+__msg_qnum__, __msg_lspid__, __msg_lrpid__, __msg_stime__ and __msg_rtime__ are set to . 
  
 __msg_ctime__ is set to the current time. 
  
+__msg_qbytes__ is set to the system limit __MSGMNB__.  
  
-__msg_qbytes__ is set to the system limit  
-__MSGMNB__
+If the message queue already exists the access permissions are verified, and a check is made to see if it is marked for  
+destruction
  
-  
-If the message queue already exists the access permissions  
-are verified, and a check is made to see if it is marked for  
-destruction.  
 !!RETURN VALUE 
+If successful, the return value will be the message queue identifier (a nonnegative integer), otherwise __-1__ with __errno__ indicating the error.  
  
-  
-If successful, the return value will be the message queue  
-identifier (a nonnegative integer), otherwise __-1__ with  
-__errno__ indicating the error.  
 !!ERRORS 
  
+For a failing return, __errno__ will be set to one among the following values:  
  
-For a failing return , __errno __ will be set to one among  
-the following values
+;[EACCES]: A message queue exists for ''key'' , but the calling process has no access permissions to the queue.  
+;[EEXIST]: A message queue exists for __key __ and ''msgflg'' was asserting both __IPC_CREAT__ and __IPC_EXCL__.  
+;[EIDRM]: The message queue is marked for removal.  
+;[ENOENT]: No message queue exists for ''key'' and ''msgflg'' wasn't asserting __IPC_CREAT__.  
+;[ENOMEM]: A message queue has to be created but the system has not enough memory for the new data structure.  
+;[ENOSPC] : A message queue has to be created but the system limit for the maximum number of message queues (__MSGMNI__) would be exceeded.  
  
-  
-__EACCES__  
-  
-  
-A message queue exists for ''key'', but the calling  
-process has no access permissions to the queue.  
-  
-  
-__EEXIST__  
-  
-  
-A message queue exists for __key__ and ''msgflg'' was  
-asserting both __IPC_CREAT__ and  
-__IPC_EXCL__.  
-  
-  
-__EIDRM__  
-  
-  
-The message queue is marked for removal.  
-  
-  
-__ENOENT__  
-  
-  
-No message queue exists for ''key'' and ''msgflg''  
-wasn't asserting __IPC_CREAT__.  
-  
-  
-__ENOMEM__  
-  
-  
-A message queue has to be created but the system has not  
-enough memory for the new data structure.  
-  
-  
-__ENOSPC__  
-  
-  
-A message queue has to be created but the system limit for  
-the maximum number of message queues (__MSGMNI__) would  
-be exceeded.  
 !!NOTES 
+__IPC_PRIVATE__ isn't a flag field but a __key_t__ type. If this special value is used for ''key'', the system call ignores everything but the lowest order 9 bits  
+of ''msgflg'' and creates a new message queue (on success).  
  
+The following is a system limit on message queue resources affecting a __msgget__ call:  
+;__MSGMNI__: System wide maximum number of message queues: policy dependent.  
  
-__IPC_PRIVATE__ isn't a flag field but a __key_t__  
-type. If this special value is used for ''key'', the  
-system call ignores everything but the lowest order 9 bits  
-of ''msgflg'' and creates a new message queue (on  
-success).  
-  
-  
-The following is a system limit on message queue resources  
-affecting a __msgget__ call:  
-  
-  
-__MSGMNI__  
-  
-  
-System wide maximum number of message queues: policy  
-dependent.  
 !!BUGS 
+Use of __IPC_PRIVATE__ does not actually prohibit other processes from getting access to the allocated message queue.  
  
+As for the files, there is currently no intrinsic way for a process to ensure exclusive access to a message queue. Asserting both __IPC_CREAT__ and __IPC_EXCL__ in  
+''msgflg'' only ensures (on success) that a new message queue will be created, it doesn't imply exclusive access to the message queue.  
  
-Use of __IPC_PRIVATE__ does not actually prohibit other  
-processes from getting access to the allocated message  
-queue.  
-  
-  
-As for the files, there is currently no intrinsic way for a  
-process to ensure exclusive access to a message queue.  
-Asserting both __IPC_CREAT__ and __IPC_EXCL__ in  
-''msgflg'' only ensures (on success) that a new message  
-queue will be created, it doesn't imply exclusive access to  
-the message queue.  
 !!CONFORMING TO 
+SVr4, SVID. SVr4 does not document the [EIDRM] error code.  
  
-  
-SVr4, SVID. SVr4 does not document the EIDRM error  
-code.  
 !!SEE ALSO 
-  
-  
- ftok(3), ipc(5), msgctl(2),  
- msgsnd(2), msgrcv(2)  
-----  
+ftok(3), ipc(5), msgctl(2), msgsnd(2), msgrcv(2) 
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.