Path: utzoo!utgpu!attcan!uunet!mcsun!ukc!stl!stc!root44!hrc63!mrcu!yh87
From: yh87@mrcu (Paul Johnson)
Newsgroups: comp.unix.wizards
Subject: Re: Strange SUN behaviour.
Message-ID: <219@oasis.mrcu>
Date: 18 Oct 89 09:49:55 GMT
References: <218@oasis.mrcu>
Reply-To: yh87@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, UK
Lines: 52
Summary:
Expires:
Sender:
Followup-To:


A couple of weeks ago I posted a notice about the death of the parent
shell when certain programs exited.  Here is a summary of the mailed
responses.  Thanks to Steve Nuchia of Houston Public Access, Seth
Robertson of Columbia University, Larry Allen of the OSF, Casper Dik
of the University of Amsterdam and David DiGiacomo of Sun
Microsystems.  To anyone else who has sent a reply before reading
this, thank-you for your time.  The problem is now solved.

My program was using fcntl(F_SETFL,...) to set the FNDELAY flag on
descriptor 0 (non-blocking mode).  In this mode, if there are no
characters waiting to be read, a read() call returns 0 or -1
(depending on your version of Unix) instead of
blocking.  This is what I had intended.  What I had not intended was
that this should affect the parent shell.  When my program terminated
abnormally (say from a kill -9), it left this flag set.  I had assumed
that something like this would be local to the process which set the
flag.  The man page on fcntl says something about affecting all
descriptors which point to that device, but I thought it meant only
those descriptors in the same process.  I still think this is
something of a mis-feature in Unix.

The solution suggested by Steve Nuchia was to include a fork in my
program.  The child would execute the main area of the program and the
parent would wait for the child to terminate and then reset the
descriptor.  I did not like this, but had I been desparate I would
probably have done it.

Seth Robertson mentioned that ksh gets around the problem and
described a program called "background" which seems to implement Steve
Nuchia's solution (or something similar).

Larry Allen agreed with me that this is a bug in Unix, and remarked
that it would be a win to fix the csh.

The solution I adopted was to abandon the use of non-blocking mode.
Instead I use select() to determine if the descriptor has any
characters waiting and then read them one by one.  The only problem I
can see with this is the possibility of race conditions if two such
programs are trying to read from the same terminal: I think both would
get a SIGIO, both would be told by select() that characters are
available, and then one would get the character and the other would
block.  However I am not too worried by this.  Another solution I
considered was to set/reset FNDELAY around every call to read().  I
may yet do this.

Paul.

-- 
-----------------------------------------------------------------------------
Send replies to paj@uk.co.gec-rl-hrc, not the address above.  Thanks.
-----------------------------------------------------------------------------
GEC is not responsible for my opinions (says my shrink).