Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ogicse!pdxgate!eecs!kirkenda
From: kirkenda@eecs.cs.pdx.edu (Steve Kirkendall)
Newsgroups: comp.os.minix
Subject: Re: Vi and alarm.
Message-ID: <2148@pdxgate.UUCP>
Date: 30 Mar 91 18:37:19 GMT
References: <2996@redstar.cs.qmw.ac.uk> <79@oski.toppoint.de> <4@oski.toppoint.de>
Sender: news@pdxgate.UUCP
Reply-To: kirkenda@eecs.UUCP (Steve Kirkendall)
Organization: Portland State University, Portland, OR
Lines: 33

In article <4@oski.toppoint.de> schlut@oski.toppoint.de (Olaf Schlueter) writes:
>>You can watch the bug working in:
>>   do { 
>>      alarm(1); n = read (1,&c,1); alarm(0) } while( n > 0);
>>}
>
>Bruce thinks, there is a race condition, the alarm may expire after the
>read, but before the alarm(0) call - this would explain, why it is
>only seen on slow machines.

There *is* a race condition in the [corrected version of] the above
code.  However, that isn't what's happening in elvis.

Any signal that is caught will either have no effect on the flow of
control in the main program, or it may cause certain slow system calls
to return with an EINTR error.  Since elvis catches the SIGALRM signal,
an alarm that happens during the read() will cause the return to have an
EINTR error; and an alarm between the read() and the alarm() will have
no effect.

For Elvis to die from a SIGALRM signal, it must be receiving two signals
after a single non-zero alarm() call.  This sounds like a bug in the
kernel.  As Bruce and Olaf say, it may be due to a race condition there,
although the fact that I've *NEVER* seen this happen on my Atari makes me
wonder.

As a work-around, I suggest you try recompiling elvis after inserting a
"signal(SIGALRM, dummy)" call just before the "alarm(0)" in tio.c.

Or, you could just ":set keytime=0" to disable this whole timeout
business.
-------------------------------------------------------------------------------
Steve Kirkendall     kirkenda@cs.pdx.edu      Grad student at Portland State U.