Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!swrinde!gatech!news.mathworks.com!news.kei.com!nntp.et.byu.edu!news.byu.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Internet Service Provider
Date: 25 May 1995 01:14:14 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 85
Message-ID: <3q0ll6$aa2@park.uvsc.edu>
References: <3pqb92$lq2@pt9201.ped.pto.ford.com> <3prh5v$au8@fnord.dfw.net> <D91uu8.7J3@twwells.com>
NNTP-Posting-Host: hecate.artisoft.com
bill@twwells.com (T. William Wells) wrote:
]
] The biggest problem with FreeBSD (2.0) that I've seen so far is
] that when connections are just "dropped" many programs go into an
] infinite read loop. I need to figure out where that's coming from
] and *fix* it, as it eats CPU time.
This is a point of POSIX interpretation.
Basically, it boils down to whether the SIGHUP sent to the process
group leader when the port is -CLOCAL and DCD drops should be sent
*before* or *after* the tty has disinherited the processes for which
it is the controlling tty and *before* or *after* the child processes
of the group leader are orphaned.
Basically, it's permissable under POSIX (but not according to me!)
to disinherit first then deliver the signal.
This results in the SIGHUP being delivered only to the process
group leader for the tty, since at the time of the signal send,
it's children are no longer in the group, and thus the SIGHUP
is inherited.
It's a bit more complicated in implementation, since the SIGHUP,
if it were propagated would be sent to the children of the
processes that were disinherited as well. This would depend on
the following order:
1) group leader gets sighup
2) group leader sends SIGHUP to children in process group
3) group leader disinherits childrent.
The magic here would be an implied wait() in _exit() before _exit()
processing has taken place.
The result on the various flavors of BSD of the current signal
implementation is that the SIGHUP is delivered to the parent
process and the DCD loss causes the disinheritance (rather than
it being done at the close). This is a hack (in my book anyway)
to get around the processes hanging around AND tying up the tty.
Now they just hang around.
The proper fix (again, in my book) would be to get them to not
hang around, so the last close can result in the disinherit.
With intermediate processes (without the implied wait) becoming
process group leaders (and the SIGHUP being sent at that time
as a persistent condition), all processes would still get the
SIGHUP.
So it's fixable with or without the implied wait (wherein the
parent would reap the child status or promote the child to
group leader by the act of exiting).
Either way the problem would be fixed.
Using the "strict" POSIX interpretation (so-called because SVR3,
SVR4, SunOS 4.x, and SunOS 5.x all use the approach I described,
without the parent implying a wait), the soloution is to use the
read/EOF indicator of 0 bytes returned on a blocking read and/or
the read should actually return -1 and have EIO status or some
other garbage like that (if POSIX had *really* intended this,
you'd think they'd have mandated an EEOF error code, or something).
In any case, the soft workaround is to trap every read error, but
if you were industrious, you *could* go in and hack the process
exit/SIGHUP handling.
Note that work is currently in progress in the SIO stuff, not
really directly related to this, so watch for falling toes.
Note also that some of the resoning for this hack was based on
some console driver attributes which aren't in common with the
tty code, though the controlling process/process group stuff is
largely shared.
Unfortunately, I haven't had a real opportunity to go in and do
the grunt-work myself to make this "just work".
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.