Date: Sat, 6 Apr 1996 17:21:08 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: roell@blah.a.isar.de (Thomas Roell) Cc: hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604070021.RAA28693@phaeton.artisoft.com> In-Reply-To: <199604060911.LAA00234@blah.a.isar.de> from "Thomas Roell" at Apr 6, 96 11:11:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, then I had 2 or 3 maybe very stupid sounding questions (and believe me, > I tried to work around them for quite a while now): > > 1) How do I get my process to be the controlling pgrp of this tty ? I > tried all things that worked under SVR4, but I'm lost on this one. > Just a couple of sample code lines would help me here incredible. The question is wrong. The correct question is "how do I make this tty the controlling tty for my process?". You are attempting to map in the wrong direction. > 2) Can my progress have two controlling ttys ? Basically this process > is also going to open /dev/ttyv3 (as an example), reading the > keyboard and also wanting to recieve a SIGIO (which fails right now > the same way). No. There is "THE controlling tty for a process group". Consider: when I have multiple tty's open, and I open /dev/tty, which tty will I get? The answer is that I will get the controlling tty. I assume you want this for SIGHUP processing? I used to work (for more than 5 years) as THE software engineer (not including the company president) for the #1 UNIX communications software (TERM). The *ONLY* reliable way to get SIGHUP delivery on two or more ttys is to use another process for each additional tty to act as the controlling process and then use an IPC mechanism to send the signals to the "master" process. We had to do this for a terminal emulation program, since I might call in and then call out of a system, and I want loss of carrier on EITHER tty to cause the program to shutdown the connection on the other tty. Consider: I call into work and I call out, long distance, and then my local power fails. Really, the entire idea of controlling ttys and signal delivery and session and process and credential association is rather broken. Unfortunately POSIX has cast it in stone and now we are all screwed if we want to be standards compliant. 8-(. > 3) Since this process has opened already a virutal terminal, he is > recieving signals for VT switching. Now if I would detach this one > from being the controlling tty and move the controlling tty to > /dev/cuaa1, would I still get those signals ? I don't know how the VT switching decides where to gsignal(), having not really cared to look (I still believe that DDX should be provided by the OS, and a signlaiing API of any kind is therefore unnecessary). I suspect it uses controlling tty in the process that has it open, so doing that would cause the signals to be blocked. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604070021.RAA28693>