escaping from a message queue deadlock...

[Robert J Woodhead]

I'm doing a little work with System V message queues, where I have
clients talking to a database server using queues as the communications
medium.  There are several points at which a hardware or software
failure can cause a hangup, and these I want to avoid, while being
as efficient as possible.

Consider the following transaction:

* client sends a "I want to send you a file" message
* server says "You have my attention, send me the file"
* client sends several "contents of the file" message
* client sends "I'm all done"
* server sends "Ok, I got all that.  Thanks."

There are several points at which the client and server can hang waiting
for a message from the other end, which, if the other end crashes, might
never arrive.  This situation, though rare, is one that needs to be
dealt with.  The simple solution would be to do something like this:

loop
   get a message from the queue of the type desired, using IPC_NOWAIT
      so we don't sleep waiting for it to arrive.
   if we didn't get a valid message, sleep(1)
until we got a valid message, or we looped "N" times.

if we didn't get a valid message
  oh_crap();

>From my point of view (which is, btw, someone who has only been puttering
around with Xenix for 8 months or so, so forgive me if this is a real
simple one), this solution has two problems:

* it's not particularly elegant
* it's not optimally efficient
* response time is slower than it should be

So basically what I need is a way to go to sleep on a message queue waiting
for A) a message of a particular type to enter the queue or B) a certain
time interval to pass.  If B happens before A, the message queue operation
needs to fail.

For simplicity, could responses be sent via mail; I will abstract the best
solutions and post them.  Messages posted to comp.unix may not get to me.
Thanks in advance.
-- 
* Robert J Woodhead * The true meaning of life is cunningly encrypted and *
* uunet!biar!trebor * hidden somewhere in this signature...               *
* Biar Games, Inc.  *                       ...no, go back and look again *