acs@amdahl.amdahl.com (Tony Sumrall) (10/20/87)
Ed Puckett has zeroed in on an AbortIO()/WaitIO() bug that is present in VT100 R2.7 but was present back in R2.6 days. The problem appears to be that sometimes, after an AbortIO(), the subsequent WaitIO() is never satisfied. Way back when this problem was originally discussed, Neil Katin of Commodore said that the AbortIO() should be followed by a Wait()/GetMsg() pair or, alternatively, a WaitIO() since the abort doesn't remove the reply. Ed changed the WaitIO() with a GetMsg() call with no intervening Wait() and, he reports, the problem disappears! Anyone got the straight scoop? Doesn't seem that, in a message passing system, one should simply do a GetMsg() without a preceeding Wait(). -- Tony Sumrall acs@amdahl.com <=> amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/21/87)
>Katin of Commodore said that the AbortIO() should be followed by a >Wait()/GetMsg() pair or, alternatively, a WaitIO() since the abort doesn't >remove the reply. Ed changed the WaitIO() with a GetMsg() call with no >intervening Wait() and, he reports, the problem disappears! > >Anyone got the straight scoop? Doesn't seem that, in a message passing >system, one should simply do a GetMsg() without a preceeding Wait(). That's a big negatory... certainly if you remove the Wait() or WaitIO() it will not endlessly wait, but the only way it could possibly have screwed up is if the aborted request was never sent in the first place. Alternately, the aborted request might have already been processed by a Wait()/GetMsg() or WaitIO() and is not pending in the IO device. Therefore, you are simply replacing the problem with a possibly more dangerous one.... since with your modification it is now possible for the request to get reused before the IO device is finished with it. Can you say CRASH? I suggest that the original WaitIO() be put back until the *real* problem is found. -Matt
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/21/87)
In article <16584@amdahl.amdahl.com> acs@amdahl.amdahl.com (Tony Sumrall) writes: } }Ed Puckett has zeroed in on an AbortIO()/WaitIO() bug that is present in }VT100 R2.7 but was present back in R2.6 days. The problem appears to be }that sometimes, after an AbortIO(), the subsequent WaitIO() is never }satisfied. Way back when this problem was originally discussed, Neil }Katin of Commodore said that the AbortIO() should be followed by a }Wait()/GetMsg() pair or, alternatively, a WaitIO() since the abort doesn't }remove the reply. Ed changed the WaitIO() with a GetMsg() call with no }intervening Wait() and, he reports, the problem disappears! } }Anyone got the straight scoop? Doesn't seem that, in a message passing }system, one should simply do a GetMsg() without a preceeding Wait(). Actually, there is a definite race condition when you use AbortIO to abort a request. Since the request may actually finish just before the call to AbortIO, if you then do a WaitIO you will never return because the there is no request there! So you probably want to add a call to CheckIO to make sure the request still exists before waiting on it, thus the code would look something like ... AbortIO(request); if (CheckIO(...)) WaitIO(request); --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
john13@garfield.UUCP (John Russell) (10/22/87)
In article <8710202353.AA25899@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >Katin of Commodore said that the AbortIO() should be followed by a > >Wait()/GetMsg() pair or, alternatively, a WaitIO() since the abort doesn't > >remove the reply. Ed changed the WaitIO() with a GetMsg() call with no > >intervening Wait() and, he reports, the problem disappears! I didn't hear exactly what the problem was... is this the situation in which you activate and "Return" in the transfer window/string gadget with no filename (after a file transfer is finished) and your cursor disappears, the program locks up, and stops responding to any input whatsoever? John -- "Operating systems room, prepare for shutdown." "I never thought I'd be HAPPY to see our ratings do DOWN!" -- lots of these were sprinkled throughout the last broadcast episode of _Max_Headroom_
acs@amdahl.amdahl.com (Tony Sumrall) (10/22/87)
In article <31537@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >Actually, there is a definite race condition when you use AbortIO to ^^^^^^^^---is this a statement of fact or opinion? >abort a request. Since the request may actually finish just before the >call to AbortIO, if you then do a WaitIO you will never return because >the there is no request there! So you probably want to add a call to >CheckIO to make sure the request still exists before waiting on it, thus >the code would look something like ... > > AbortIO(request); > if (CheckIO(...)) WaitIO(request); I took the postings back in May to mean that AbortIO() will work correctly regardless of the "state" of the request (i.e. completed or not). If the request *has* completed you should have a signal waiting for you, no? The AbortIO() shouldn't diddle with pending signals should it? I don't think so but a little inside knowledge would help here (C-A, you there :-). Nonetheless, your stated method may work and I'll give 'er a try once I have a free hour or so. BTW, if anyone is interested in a transcript of the postings that I keep alluding to I'd be happy to ship you a copy...just send me some mail. >--Chuck McManis -- Tony Sumrall acs@amdahl.com <=> amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/22/87)
>Actually, there is a definite race condition when you use AbortIO to >abort a request. Since the request may actually finish just before the >call to AbortIO, if you then do a WaitIO you will never return because >the there is no request there! So you probably want to add a call to >CheckIO to make sure the request still exists before waiting on it, thus >the code would look something like ... Nope, there isn't. WaitIO() returns immediately if the request has already completed. Therefore, one proper sequence is: AbortIO(request) WaitIO(request) Which (A) asks the device driver to please abort the request and (B) waits for the request to be returned. You can then check io_Error to see if the request completed before it could be Aborted. (A device which does not support AbortIO() simply continues processing the request and it is returned normally). As I said before, the only way WaitIO() might freeze up is if the request was never sent to the device... for example, two WaitIO()'s in a row without an intervening Do/SendIO. As far as the serial device goes, there is another possibility... If the serial device is XOFF'd WRITE io requests will not be returned until it is XON'd again, or a FLUSH sent to the serial device. Any terminal program which uses XON/XOFF and which doesn't have a timeout limit for serial write's (before it tries to AbortIO them) might freeze up on a spurious XON. -Matt
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/22/87)
In article <16749@amdahl.amdahl.com> (Tony Sumrall) writes: >In article <31537@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >>Actually, there is a definite race condition when you use AbortIO to > ^^^^^^^^---is this a statement of fact or opinion? This was stated as a fact by the CATS staff on BIX. At the time the context was calling the printer device, and it was later generalized to all devices. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
acs@amdahl.amdahl.com (Tony Sumrall) (10/27/87)
In article <31678@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <16749@amdahl.amdahl.com> (Tony Sumrall) writes: >>In article <31537@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >>>Actually, there is a definite race condition when you use AbortIO to >> ^^^^^^^^---is this a statement of fact or opinion? > >This was stated as a fact by the CATS staff on BIX. At the time the >context was calling the printer device, and it was later generalized >to all devices. Not that I don't trust you, Chuck but could someone from CATS please confirm this?...it's wreaking havoc with my sleep-time (yawn). Specifically, Chuck said: > Actually, there is a definite race condition when you use AbortIO to > abort a request. Since the request may actually finish just before the > call to AbortIO, if you then do a WaitIO you will never return because > the there is no request there! So you probably want to add a call to > CheckIO to make sure the request still exists before waiting on it, thus > the code would look something like ... > > AbortIO(request); > if (CheckIO(...)) WaitIO(request); >--Chuck McManis Many thanks!! -- Tony Sumrall acs@amdahl.com <=> amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
dpvc@ur-tut.UUCP (Davide P. Cervone) (10/28/87)
In article <31537@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >Actually, there is a definite race condition when you use AbortIO to >abort a request. Since the request may actually finish just before the >call to AbortIO, if you then do a WaitIO you will never return because >the there is no request there! So you probably want to add a call to >CheckIO to make sure the request still exists before waiting on it, thus >the code would look something like ... > > AbortIO(request); > if (CheckIO(...)) WaitIO(request); > >--Chuck McManis While we're discussing AbortIO(), does anyone know how to abort a DUMPRPORT request? I posted a notice some time ago that outlines my problem, and received no answer, so I'll try again. I do a SendIO() and then sometime while the DUMPRPORT is being performed, call AbortIO() and Wait(). All seems to work just fine. The printing stops, and the Wait() returns OK. The problem comes when I ask to do ANOTHER DUMPRPORT. Nothing happens. The IO never completes, but never starts either. I've checked all the error codes, and none of them are unusual. Frankly, I'm stumped. Is there some way I can cancel a DUMPRPORT? AbortIO() is not covered in the Printer.Device documentation, so maybe I can't really call it for that? Does CMD_STOP and CMD_START (I may have the names wrong) work for DUMPRPORT requests? They don't seem to have any effect when I use them. I'm sure I'm missing something fundamental... Thanks for your help. Davide P. Cervone dpvc@tut.cc.rochester.EDU dpvc@ur-tut.UUCP DPVC@UORDBV.BITNET