Path: utzoo!attcan!uunet!mcsun!cernvax!chx400!ethz!stp
From: stp@ethz.UUCP (Stephan Paschedag)
Newsgroups: comp.os.os9
Subject: Re: signal problem
Message-ID: <5710@ethz.UUCP>
Date: 25 Aug 90 11:25:21 GMT
References: <5596@ethz.UUCP> <3943@disk.UUCP> <5671@ethz.UUCP> <57281@wlbr.IMSD.CONTEL.COM>
Reply-To: stp@bernina.ethz.ch.UUCP (Stephan Paschedag)
Organization: ETH Zuerich, Switzerland
Lines: 27

In article <57281@wlbr.IMSD.CONTEL.COM> pete@wlbr.imsd.contel.com.UUCP (Pete Lyall) writes:
>If you have a signal handler routine setup  (either signal() or
>interrupt()), you can just set a flag that indicates that a
>signal was received, and probably what kind of signal it was. Then,
>you just exit the intercept handler. The I/O should complete normally,
>and then you can manually check the flag yourself.
>
>Pete

But the intercept handler is NOT executed unless you exit from the Driver
i.e. the count of written data is lost !!! The process can't find out
how many bytes have been written until the signal has occured. And if you
just ignore the signal after the F$Sleep in the driver and exit from the
driver when all data has been written (which can take quite a while !) you
don't have a realtime system anymore. 
One way to solve the problem would be to a SS_Free GetStt to the driver
which gives me the amount of free buffer space in the driver, but as far
as the GetStt is not supportet by all SCF drivers it doesn't solve my problem.

Stephan

==============================================================================
OS/2 & PS/2 : half an operating system for half a computer

Stephan Paschedag                                         stp@ethz.UUCP
MPL AG, Zelgweg 12, CH-5405 Baden-Daettwil     ..!mcvax!cernvax!chx400!ethz!stp
______________________________________________________________________________