Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!cfisun!lakart!dg
From: dg@lakart.UUCP (David Goodenough)
Newsgroups: comp.mail.uucp
Subject: who has the line (was Re: Bidirectional Modem Lines ....)
Message-ID: <492@lakart.UUCP>
Date: 14 Apr 89 03:32:54 GMT
References: <1403@auspex.auspex.com>
Organization: Lakart Corporation, Newton, MA
Lines: 27

From article <1403@auspex.auspex.com>, by guy@auspex.auspex.com (Guy Harris):
> Huh?  Its sole purpose is to prevent two programs ("getty" and the
> program that's dialing out) from gaining simultaneous access to the same
> serial line.

I thought tip / uucico did that when they opened the line. Usually an idle
getty looks like this:

       F UID   PID  PPID CP PRI NI ADDR  SZ  RSS WCHAN  STAT TT  TIME COMMAND
 1800001   0  4872     1  0   3  0  5d8  40   28 cp_tty I    h1  0:00 - std.960

where the cp_tty means it waiting for a tty to do something. I'd do it now
but I'm dialed in (catch 22 :-) ), but when uucico / tip are running, the
WCHAN changes to a 'u', and the stat goes to a 'S' (short term snooze). So
either uucico does some explicit widgetry to nuke the getty, or the open does.
I once started writing a term program, and since I'm on a BSD system, I opted
to check for a getty on the line, and if there just issue a kill -17 at it.
Held that sucker quiet real good :-). If I couldn't, I assumed that the tty
was in use and exited the term prog.

Anyway what does happen when the WCHAN changes from cp_tty to u??
Enquiring minds want to know.
-- 
	dg@lakart.UUCP - David Goodenough		+---+
						IHS	| +-+-+
	....... !harvard!xait!lakart!dg			+-+-+ |
AKA:	dg%lakart.uucp@xait.xerox.com		  	  +---+