Related links

Ask the Wizard Questions

Problems with one process communicating with its subprocess through a mailbox

The Question is:

I am facing one serious problem. I have one process communicating
with its subprocess through a mailbox. Communication basically
involves huge data transer from main process to subprocess. Subprocess
carries out processing on each set of data, read through the mailbox.

This works fine for small data file transfer. While transfering
large file data, sometimes, main process hangs and the process
state shows as RWMBX.

I increased the DEFMBXBUFQUO ( sygen parameter ) value, as well
as, the bufquo argument (in sys$crembx call) to sufficiently large
value (ie, 8192 from 1024 ). This works out fine for only few
large files and not for all. Increasing the bufquo value to very
huge value, (say, 20480 ) is causing the subprocess to get killed.

Can anyone help me by suggesting the suitable solution to solve
my problem. Also, inform me about different conditions, on which
the process goes to RWMBX state.

I am having Alpha-Axp system, running Open VMS 6.1.

Thanks in Advance,

The Answer is:

The root cause of the problem you are running into is that
mailboxes are a good inter-process communication mechanism, but
are not suitable for buffering large amounts of data. Unlike a
Unix pipe, in which data in the pipe is stored on a file in the
file system, an OpenVMS mailbox stores all buffered data in real
memory. The mailbox buffer quota that you specified with either
DEFMBXBUFQUO or the bufquo argument sets the limit on the amount
of data you can buffer in the mailbox.

When you create the mailbox, the buffer quota you specify is deducted
from your job's non-paged dynamic memory (pool) quota. (This is
the quota AUTHORIZE shows as BYTLM.) This quota governs pool usage
by the main process and all subprocesses in your job; most system
services require some amount of pool quota. So if you give too
much of your job's pool quota to the mailbox, your job won't have
enough quota left to run.

The reason the main process is going into RWMBX state is that
it is getting ahead of the subprocess's ability to read and process
the messages from the mailbox. When the mailbox is full, further
attempts to write the mailbox will put the process into RWMBX
state until the subprocess reads from the mailbox.

Depending on the requirements of your application, there a couple
of choices you have to deal with this problem:

Do nothing. If there is nothing else for the main program
to do while it is piping the data to the subprocess, letting it
go into RWMBX is harmless. The system is providing automatic flow
control for you on the mailbox.

Use synchronous I/O. Write each message with IO$_WRITEVBLK
*without* the IO$M_NOW modifier. Wait for the write I/O to complete,
either by using the $QIOW service for a fully synchronous write,
or by using $QIO to initiate the write and later waiting on its
completion with $SYNCH. Without the IO$M_NOW modifier, each write
will complete only when the subprocess has read that message from
the mailbox. By using $QIO and $SYNCH, you can keep a limited
number of messages in the mailbox at all times without stalling
the process in RWMBX.

Buffer the messages in the subprocess. In the subprocess,
use an asynchronous $QIO with a completion AST to read the mailbox.
In the AST routine, put the buffer you just read onto a work queue.
Then allocate another buffer and issue a new read $QIO before
returning to your data processing. This way the subprocess will
drain the mailbox as fast as it can issue and complete read $QIOs,
and process the data in the background.