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 *