HP OpenVMS Systems

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:

1. 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.
2. 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.
3. 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.