Tom writes:
> I'm getting "something strange" when dealing with message files, NOWAIT
> I/O, and "interrupt" procedures, and since it now has me baffled,

Every time I think I understand Message Files, they turn out to have some
fundamental behavior that is completely different from what I expected.

> Basically, what appears to happen is this: if "someone else" has the
> message file open for writing AND there is at least one record in
> the file, when this process opens the file, sets "extended wait",
> sets "non-destructive read", and issues an FREAD, NO "interrupt"
> occurs [I have my interrupt procedure displaying a message whenever
> an interrupt occurs -- no message = easy to infer no interrupt
> actually occurred]

If you had asked me what would have happened, my guess would have been that
interrupts would be triggered only by the writing of a new record to the
file rather than by the existence of records in the file, which would
explain what you are seeing.

[...]
> This worked great when there was a single server
> process.  in order to handle a greater load, I've expanded the process to
> three server processes by maintaining an array of inbound/outbound message
> pairs in which I write messages in a round-robin fashion.

The "message file" way of handling this would generally be to have a single
input message file to which all three clients would submit requests, at
which point the "round-robin" problem takes care of itself since the "next
available" server process will see each request.

Now you'll ask what the behavior of soft interrupts will be in the case of
multiple readers, and I have to say that I really don't know for sure.  A
guess would be that an interrupt will be delivered to every reader for every
new record that's written, and each reader will have to consider the
possibility that someone else will have read the input record by the time it
gets to it.

One question would be why are you using soft interrupts in the first place
rather than just having one IOWAIT or HPSELECT that waits on all your input
sources at the same time so that interrupts aren't really needed.

> This may be where I'm getting myself into trouble: all three of
> the "inbound" message files SHARE the same interrupt procedure.

I don't *think* this should be a problem.

> Strangely enough, if I start this process the first time, everything
> appears to go well.  When I shut down the "client", I send a
> terminating "$EOD" message which the server bounces back as before [this
> way I know the outbound queue has been processed]  SOMETIMES (but not
> always) this $EOD never returns [but I see evidence from my server that it
> has written the $EOD: after everything has "shut down", I see the message
> file DOES contain the $EOD !]  Then, whether or not the $EOD returns [and
> is recognized],

Sounds like a possible bug.

> if I RESTART this process without first clearing the file,
> no interrupt is EVER generated!

Even if new records are written to the file?  This *sounds* like a bug.

Again, I'd first evaluate whether you really need the soft interrupt stuff
at all.  You also might look at using the open/close records of the message
files with, or in replacement for, some of the $EOD message functionality
since they have the advantage of being guaranteed to be written even if the
writer crashes.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *