On Fri, Aug 06, 2010 at 02:41:22PM -0400, James Carlson wrote: > Edward Pilatowicz wrote: > > On Fri, Aug 06, 2010 at 01:05:38PM -0400, James Carlson wrote: > >> Richard L. Hamilton wrote: > >>> James Carlson wrote: > >>>> For what it's worth, I would use > >>>> fork()/setsid()/fork() to disclaim a > >>>> controlling tty. It's simple and always works. > >>>> (Though, notably, it > >>>> oes not get you outside of an existing contract, > >>>> which is sometimes an > >>>> important distinction for programs that operate as > >>>> daemons.) > >>> That's exactly what I wanted to avoid, using a sort of > >>> semi-daemonizer program that would leave backgrounding > >>> up to the invoker, so that if the invoker wished, it could > >>> collect status to discover any failures. That's a little > >>> tricky to do with fork()/setsid()/fork(), taking into account > >>> the possibility of non-zero return codes or signals (with or without > >>> core dumps). > >> That's what Solaris contracts are (at least partly) about. They allow > >> you to monitor children that may go through multiple forks. > >> > >> I can't say I'd recommend TIOCNOTTY for any new code intended to run on > >> Solaris. But good luck. ;-} > >> > > > > i implemented TIOCNOTTY support as part of the original brandz project. > > we needed it for the lx brand, since fork()/setsid()/fork() wasn't > > really an option for emulating TIOCNOTTY. since then the lx brand has > > been retired, but we've kept TIOCNOTTY for compatibility. it's a public > > interface documented in termio.7i (on nevada at least). i don't think > > there's any reason for us to remove it, so i don't really think there's > > any reason to recommend not using it. > > I don't think it should be removed, and it's nice that you folks added > it. I wasn't in any way suggesting removal. > > The reasons I'd recommend avoiding _using_ it are: > > - fork/setsid/fork prevents you from accidentally acquiring a new > controlling tty in the future. This can happen in surprising ways, > such as having a logging library open the console, or just a stray > open() unadorned by O_NOCTTY, if you're still a process group > leader after you do TIOCNOTTY. > > - The setsid call will work on older versions of Solaris, but > TIOCNOTTY will not. Though this is opensolaris.org, many of us > working on OpenSolaris still need to support S8, so it can be an > important consideration. > > - fork/setsid/fork always works and doesn't require you to have > access to a stream opened on the controlling tty, doesn't require > you to be the process group leader, or anything else. It "just > works." >
all valid reasons, we just don't know how those reasons match up with richard's requirements, so i just wanted to point out that it is an existing and supported interface. > > that said, there is one restriction on the caller of the interface. > > specifically, the process calling it must be a session group leader. > > here's the man page blurb from nevada: > > > > ---8<--- > > TIOCNOTTY Takes no argument. Release the controlling > > terminal associated with the current > > processes session group. The calling pro- > > cess must be the session group leader to > > issue this ioctl. > > ---8<--- > > So, your program will run as expected if it's just run by itself, but if > it's put in a pipeline, it'll fail to release the controlling tty, right? > i didn't really consider pipeline behavior. the restriction to the controlling process has more to do with the fact that on solaris a ctty is associated with a session, not a process. so you can't clear a ctty for a single process in a session, only for all the processes in a session. ed _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
