Path: utzoo!attcan!uunet!samsung!dali.cs.montana.edu!rpi!bu.edu!orc!inews!iwarp.intel.com!gargoyle!igloo!ddsw1!corpane!disk!stevenw
From: stevenw@disk.UUCP (Steven Weller)
Newsgroups: comp.os.os9
Subject: Re: signal problem
Message-ID: <3979@disk.UUCP>
Date: 26 Aug 90 14:03:06 GMT
References: <5596@ethz.UUCP> <3943@disk.UUCP> <5671@ethz.UUCP>
Organization: Digital Information Systems of Ky (DISK), Louisville, Ky
Lines: 38

stp@ethz.UUCP (Stephan Paschedag) writes:

>What about the following situation :


>   A process has setup a intercept handler to catch ALL signals 
>   (including SIGQUIT & SIGINT). The process has to do some some
>   special operation on each of the signals (especially on SIGQUIT
>   and SIGINT). Now the process is doing a I$Write to a SCF device.
>   During this write the output buffer of the device driver becomes
>   full and a F$Sleep for the process is executed. During this
>   sleep a SIGQUIT arrives, the process exits from the F$Sleep call
>   and the driver recognises the signal and exits with the Carry bit
>   set and the Error code in d1.w. How can the process find out how
>   many characters have been written to the device ? (the count of
>   written characters shound also be returned in d1 !!!

>   Any ideas for a solution ?

>  Stephan

I think the quick answer is that you cannot know.  If the file manager
could tell you how many characters had been sent, it would tell you
how many were sent to the _driver_, not to the device.  

One solution is to have the driver keep track of the number of
characters sucessfully transmitted, using a GetStat call to return
that value and reset it to zero.

Another solution is to use a file manager line SPF that passes 
packets of characters to the driver and lets the driver return the
number of characters transmitted before an error occurred.

-- 
: Phone: (502) 425 9560   <<  Steven Weller  >>   Fax: (502) 426 3944 :
:   Windsor Systems, 2407 Lime Kiln Lane, Louisville, KY, 40222 USA   :
:      "A substance almost, but not quite, entirely unlike tea"       :
:        stevenw@disk.UUCP or uunet!ukma!corpane!disk!stevenw         :