stp@ethz.UUCP (Stephan Paschedag) (08/18/90)
Hi There !
I have a Question about signal handling of the OS-9/68k kernel.
Situation :
I have a filemanager which has executed a F$Sleep call (time=0).
During that sleep a signal arrives for the sleeping process.
Question :
Is it necessary to exit from the FM to ensure that the intercept-
handler of the process is called.
Or is the intercept handler called before the process returns from
the F$Sleep (system state !), so that the FM can ignore the
unexpected return from the sleeping state :
Loop: moveq.l #0,d0
os9 F$Sleep
bcs.s Loop (E$NoClk is ignored for this example !)
Thanks in advance for your help !
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
______________________________________________________________________________stevenw@disk.UUCP (Steven Weller) (08/20/90)
stp@ethz.UUCP (Stephan Paschedag) writes: >Hi There ! >I have a Question about signal handling of the OS-9/68k kernel. >Situation : > I have a filemanager which has executed a F$Sleep call (time=0). > During that sleep a signal arrives for the sleeping process. >Question : > > Is it necessary to exit from the FM to ensure that the intercept- > handler of the process is called. > Or is the intercept handler called before the process returns from > the F$Sleep (system state !), so that the FM can ignore the > unexpected return from the sleeping state : > Loop: moveq.l #0,d0 > os9 F$Sleep > bcs.s Loop (E$NoClk is ignored for this example !) >Thanks in advance for your help ! IYour second guess is correct. OS-9 queues signals that are received by a process, calling the intercept routine before the process is given CPU time (note that the intercept routine uses time out of the process time slice). This is true of the later versions of OS-9. Earlier versions did not have a queue for signals. It is worth checking the signal code in your program fragment. If it is a fatal signal - hangup, quit, abort etc. then you should return with the signal code as the error number with the carry flag set. If you don't do this, someone may be bashing away at the ^E key and getting very frustrated ! For a similar reason, check if the process has been killed. The condemn bit in the process state will be set if this is the case. Exit with a 224 error. Hope this helps, Steve -- : 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 :
stp@ethz.UUCP (Stephan Paschedag) (08/24/90)
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 ============================================================================== 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 ______________________________________________________________________________
pete@wlbr.IMSD.CONTEL.COM (Pete Lyall) (08/25/90)
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
--
Pete Lyall Contel Corporation
Compuserve: 76703,4230 OS9_Net: (805) 375-1401 (24hr 300/1200/2400)
Internet: pete@wlbr.imsd.contel.com UUCP: {hacgate,jplgodo,voder}!wlbr!pete stp@ethz.UUCP (Stephan Paschedag) (08/25/90)
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 ______________________________________________________________________________
stevenw@disk.UUCP (Steven Weller) (08/26/90)
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 :