Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.terminals
Subject: Re: Problem with code posting which determines session emulation :(
Message-ID: <15345@smoke.brl.mil>
Date: 27 Feb 91 21:17:44 GMT
References: <9102270422.AA01656@sun.soe.clarkson.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 13

In article <9102270422.AA01656@sun.soe.clarkson.edu> AAron@sun.soe.clarkson.edu writes:
>and the code should kick out of the read(2V) when the alarm(3V) goes off.
>Even after the SIGALRM I am stuck in the read(2V) !! AAAaaaarrgh!

Sounds to me like you've been bitten by another "Berkeley Better Idea".
With 4.2BSD, "slow" system calls such as reads from terminals always
get restarted by the kernel when the interrupt handler resumes.  I've
published a really horrible user-mode hack for working around that
behavior (in the signal() implementation for my System V emulation).
4.3BSD provided official support for overriding that behavior; one
sets the SV_INTERRUPT bit in the sv_flags member of the structure
passed to the sigvec() system call that plants the interrupt handler
(in place of the usual signal() call).