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