Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!swrinde!ucsd!pacbell.com!pacbell!att!dptg!lzga!bogatko
From: bogatko@lzga.ATT.COM (George Bogatko)
Newsgroups: comp.unix.wizards
Subject: Re: Help needed with System V message queues
Summary: how they work (part of article
	 that was trashed)
Keywords: SYSV messagequeue
Message-ID: <1992@lzga.ATT.COM>
Date: 8 Aug 90 16:51:25 GMT
References: <1169@compel.UUCP>
Organization: AT&T BL Middletown/Lincroft NJ USA
Lines: 54


Postnews (or something) trashed the ending of the message queue article.
Here's the ending.

******

When sending messages, the third parameter must be the size of
the actual message, not the size of the 'struct msgbuf', which
will be sizeof(long) bytes bigger.  If you don't pay attention
to this, you will get message trashing.   I can't recall now how,
when, or why this happens, but I guarantee that it will be mysterious,
and usually fatal.

		 struct msgbuf {
			 long    mtype;	  /* message type */
			 char    mtext[1];       /* message text */
		 };

So the safe way to use 'msgsnd' is:

typedef struct {
	long mtype;
	struct {
		char buf[10];
		int xxx;
		double yyy;
		etc...
	} mtext;
} MSG;

MSG message;

	1. msgsnd( msqid, &message, sizeof(message.mtext), 0);
OR
	2. msgsnd( msqid, &message, sizeof(message)-sizeof(long), 0);

I prefer #1.

I also prefer to send message with the fourth parameter as 0.  This will
make the message block if there is no room at the time.  It is more normal
for the message to block in a heavily loaded system then not, so you
will probably NOT want to die if you can't send the message because
there's no room.  If you are worried about deadlock, put in an
alarm call so you can time out.

When receiving messages, check for EINTR if you get a -1.
You will usually want to just wrap around and try again if you get
an interrupt (usually from an alarm call, or some other friendly signal).


Hope this (long-winded) yakking helps somebody.


GB