RFORSTER@UNCAEDU.BITNET (04/29/87)
From: <RFORSTER%UNCAEDU.BITNET@wiscvm.wisc.edu>
Subject: printer device bug (I think)
A friend of mine asked me to post this to the net as he does not have
write access to it.
/Russ
In a recent programming project where I needed to be able to cancel a
printer dump raster port that was in progress at the user's request I
came across a problem for which I have the only possible explaination.
It seems that the printer device keeps using something in the messages
you send it EVEN AFTER it has replyed to them! I was trying to abort a
graphics dump that had been started by the dump raster port command and
which was in the process of writing on the printer with either the
FLUSH, AbortIO(), or RESET commands (I tried all three ways separately)
and kept getting unpredictable GURUs. I say unpredictable because
sometimes the abort would work and I could sometimes do several attempts
aborting each one successfully, however eventually I would get a
VISITATION.
Eventually I found that by putting in Delays() I could get the problem
to go away to the level that maybe 1 time in 10 or 20 a GURU would
meditate. After much hair loss and a sudden lightning strike I finally
realized what the problem had to be.
TASK PRIORITIES! It seems that if the program is running at the same
priority (level 1) as the printer.device then task switching between the
two can happen in such a way that the printer.device Replys() to a message
it is JUST ABOUT done with and then my program gets a chunk of time,
receives the reply, stops Wait()ing and frees up the message packet.
The tasks then get switched again and the printer device uses something
else in the message, but another piece of system software (the input.device
perhaps) has already made use of this recently freed piece of memory,
and the GURU drops by.
I do not know if this is really what is happening, but if I run my program
at a priority level BELOW that of the printer device the code functions
perfectly, but will GURU at about a 1 try in 3 rate when run at the same
priority.
Would someone in Commodore have a look at the printer.device source to see
if it does continue to make some use of the incomming messages AFTER it
has Reply()ed to them?
Stephen (the Bug) Vermeulen
(CHHH) (AMUC)
I have all the protection I need,
I have a PAGE EATER, for a small
fee you can have one too...
--
"We must acknowledge, once and for all, that the
purpose of diplomacy is to prolong a crisis."
- Spock
Russell M Forster
BITnet: RForster@UNCAEDU.BITnet
ARPA: OC.Russ@CU20B.Columbia.Edu
CPS: Mount Royal College
4825 Richard Rd. SW.
Calgary, Alberta
Canada, T3E 6K6
Voice: (403) 240-6052
Opinions expressed herein are my own, and do not necessarily represent
those of my employer or anyone else for that matter.carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) (04/30/87)
In article <1610@rutgers.RUTGERS.EDU> RFORSTER@UNCAEDU.BITNET writes: >From: <RFORSTER%UNCAEDU.BITNET@wiscvm.wisc.edu> > >Subject: printer device bug (I think) >[] >It seems that the printer device keeps using something in the messages >you send it EVEN AFTER it has replyed to them! I was trying to abort a >graphics dump that had been started by the dump raster port command and >which was in the process of writing on the printer with either the >FLUSH, AbortIO(), or RESET commands (I tried all three ways separately) >and kept getting unpredictable GURUs. I say unpredictable because >sometimes the abort would work and I could sometimes do several attempts >aborting each one successfully, however eventually I would get a >VISITATION. >[] There may be problems in the printer's handling of aborted requests, but the GURU should only be visiting if you failed to remove the request. To abort an asynchronous (SendIO()'d) printer request, try: if(!Checkio(ioreq)) { AbortIO(ioreq); } WaitIO(ioreq); <--- Removes the request Your GURU problems should disappear. Unfortunately, some memory will also disappear since the current printer.device is unable to de-allocate graphic buffers when a DUMPRPORT request is aborted. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=