Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!ka
From: ka@june.cs.washington.edu (Kenneth Almquist)
Newsgroups: comp.unix.questions
Subject: Re: Insufficient Resource Error on msgsnd Call
Keywords: msgsnd, msgrcv, Ingres, UNIX, System V, message queues, Sun, SunOS4.0
Message-ID: <8340@june.cs.washington.edu>
Date: 25 May 89 00:23:24 GMT
References: <1023@dinl.mmc.UUCP>
Organization: U of Washington, Computer Science, Seattle
Lines: 32

>    +--------+                +--------+                +--------+
>    |        |      +-----+   |        |      +-----+   |        |
>    | Proc A |---->>| Q 1 |-->| Proc B |---->>| Q 2 |-->| Proc C |
>    |        |      +-----+   |        |      +-----+   |        |
>    +--------+                +--------+                +--------+

This setup can deadlock if the value of msg_qbytes for queue 1 is too
large.  The sequence of events is:

    0)	Queue 2 is empty.
    1)	Process B reads a message from queue 1.
    2)	Process A writes lots of messages to queue 1, exhausting the global
	message buffer space.
    3)	Process B tries to write a message to queue 2, but can't because
	the global message buffer space is exhausted.

If this is your problem, then you can fix it by limiting the quantity of
messages outstanding on queue 1 to prevent the global message buffer space
from being exhausted.  (This is done by using the IPC_SET command of the
msgctl system call to set msg_qbytes to a smaller value.)

On the other hand, you write:

> Queue 2 looks empty because Process C is blocking on it (using
> msgsnd with IPC_WAIT) ...
> reading Queue 2 several times breaks the log jam and the system runs
> for a while ...

If you can read messages off of queue 2 while process C is blocked on a
read, that indicates a kernel bug.  Probably the msgsnd system call is
failing to call wakeup for some reason.
				Kenneth Almquist