Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!root%bostonu.csnet@CSNET-RELAY.ARPA
From: root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr)
Newsgroups: net.unix-wizards
Subject: Re: A SYSV MSG question
Message-ID: <2623@brl-tgr.ARPA>
Date: Wed, 30-Oct-85 14:47:46 EST
Article-I.D.: brl-tgr.2623
Posted: Wed Oct 30 14:47:46 1985
Date-Received: Fri, 1-Nov-85 02:49:40 EST
Sender: news@brl-tgr.ARPA
Lines: 49


Sorry, I realized just after that flew out of here that I hadn't
indicated that running out of system resources I think is eliminated.
(tho nothing in my message explained that, sorry.)

Briefly:

	process 1 opens a msgq and sets it down to 40 bytes
	and loops messages to it till it blocks (it is a 'unique
	magic cookie server' to dish out unique id's to other
	processes that need them for my application, I write a
	bunch till I block just to take advantage of buffering
	so several quick requests can be serviced w/o having to
	wait for the server process to wake up, it may have been
	dormant for hours and thus swapped out or something, just
	seemed to make sense.)

	process 2 opens a different msgq w/o diddling anything, and
	writes bufs to it, typically a few hundred bytes long each. ipcs
	indicates the max qbytes to be 16K (the default.)

The problem again: as soon as process 1 blocks (with 40 bytes in the q)
process 2 blocks, even if it's the first write (it printfs to me
"Putting buf on q.." and then never proceeds (it would say "Just put
junk on q" if it finished.) IPC_NOWAIT added makes it return EAGAIN,
but I kinda knew that so that is no help. 

If I kill process 1 and ipcrm its q process 2 suddenly wakes up and
proceeds fine, putting lots of messages on the q, if I re-start process 1,
as soon as it blocks process 2 blocks again.

IPCS reveals only 3 queues active on the system, MSGMNI is 8, but
that should cause a failure from MSGGET anyhow, not blocking.

I agree, it sounds like someone ran out of resources, or I misunderstand
something entirely which is more what I am worried about. Everything
I have read (and reason) indicate that the q's should be independant
things up to system resources at which point I can understand a block.

I have to go over all the code with a fine tooth comb, I was just
hoping someone out there might recognize the problem, if it's not something
you have seen before, don't lose any sleep over it, I'll figure it out
if I have to trace the kernel. Ya know, some weird unspoken like the kernel
blocks all jobs in a pgrp if one is blocked on a msgop (tho I highly doubt
it.)

Thanks in advance.

	-Barry Shein, Boston University