On Fri, 27 Apr 2001 15:01:40 -0700, Gavin Scott <[log in to unmask]> wrote:

>Tom writes:
>> 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, [...] NO "interrupt" occurs
>
>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.

That's the trouble with thinking :)  My line-of-thought was that an
FREAD "sets" the file to a state where an interrupt can [and should] occur,
the existance of prior records shouldn't matter, and in fact the interrupt
should occur immediately after the FREAD call completes.  I suspect this
could get into "race" conditions if my internal "has an interrupt occured"
flag is RESET after the FREAD call, in which the sequence would be:

   file opened NOWAIT
   FREAD ISSUED
   <<interrupt occurs, sets "flag" variable>>
   flag variable reset by main-line logic
   [...]
   while not (flag) [pause...]

BUT, of course I already thought of that and I reset the flag prior to the
FREAD call... :)

>[...]
>> 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.

The other "servers" are >ahem< "legacy" -- they actually open 32 "pairs" of
message files so that return messages go back to the "proper" client
[mulitple clients, multiple servers...]

>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.

Actually, it's worse than that: the "server" process issues a non-
destructive read, processes the message, writes the reponse, the issues a
DESTRUCTIVE read.  This is to ensure no messages are "lost" due to the
server crashing [nice idea in theory, but in practice if the server
crashes, the jobstream that runs the server purges & rebuilds the message
files anyway...]

>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.

The reason was inferred by the closing BTW comment: this program handles
both (berkeley) socket I/O and message file I/O.  Message file interrupts
will "interrupt" the "select()" call, thus allowing my program to call
select with a zero "timeout" parameter [block until at least one socket
is "ready"]  (select returns -1 and "errno" is set to EINTR, I think]  The
converse is not true, however: "socket" activity won't interrupt IOWAIT
(0,...) [and since sockets initiate the whole message chain, nothing would
happen...]  I suppose I could code the IOWAIT to include a timeout, but
that changes my program from a "nice" block-until-ready program to
a "greedy" poll-repeatedly-thus-chewing-up-cpu-cycles program ;)

>> When I shut down the "client", [...]  SOMETIMES (but not
>> always) this $EOD never returns [but ... the message
>> file DOES contain the $EOD !]
>
>Sounds like a possible bug.
>
[I should have said the $EOD being written to the file doesn't generate an
interrupt...]

>> 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.
>
Again, I'm working with a legacy server that serves multiple clients --
because "my" client shut down doesn't mean the server shuts down [and, in
fact, it leaves the outbound-from-the-server message file open after
sending $EOD, so there would never be a "close" record in the message file]

Thanks for the insight -- just formulating a response to your questions has
given me an idea or two to pursue... :)

Tom

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