Re: Sending signals to a subprocess

[Ken Brown <kbrown at cornell dot edu>]

On 10/18/2010 4:18 PM, Christopher Faylor wrote:
> On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
> > On 10/18/2010 2:34 PM, Christopher Faylor wrote:
> > > On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
> > > > On 10/16/2010 1:17 PM, Ken Brown wrote:
> > > > > I could use some help fixing a longstanding bug in the Cygwin build of
> > > > > emacs, in which emacs is unable to send signals to subprocesses.  A
> > > > > symptom from the user's point of view is that one cannot interrupt a
> > > > > process in shell mode by typing C-c C-c.  I've found a workaround that
> > > > > handles that case (SIGINT), as well as SIGQUIT and SIGTSTP.  But as long
> > > > > as I'm fixing this, I'd like to do it right and figure out how to handle
> > > > > all signals.
> > > > >
> > > > > This boils down to finding the right process group ID to pass to 'kill'.
> > > > > On systems that have TIOCGPGRP, emacs uses the following code (in
> > > > > src/process.c) to get this ID:
> > > > >
> > > > > /* Return the foreground process group for the tty/pty that
> > > > >        the process P uses.  */
> > > > > static int
> > > > > emacs_get_tty_pgrp (p)
> > > > >          struct Lisp_Process *p;
> > > > > {
> > > > >       int gid = -1;
> > > > >
> > > > > #ifdef TIOCGPGRP
> > > > >       if (ioctl (p->infd, TIOCGPGRP,&gid) == -1&&    ! NILP (p->tty_name))
> > > > >         {
> > > > >           int fd;
> > > > >           /* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
> > > > > 	 master side.  Try the slave side.  */
> > > > >           fd = emacs_open (SDATA (p->tty_name), O_RDONLY, 0);
> > > > >
> > > > >           if (fd != -1)
> > > > > 	{
> > > > > 	  ioctl (fd, TIOCGPGRP,&gid);
> > > > > 	  emacs_close (fd);
> > > > > 	}
> > > > >         }
> > > > > #endif /* defined (TIOCGPGRP ) */
> > > > >
> > > > >       return gid;
> > > > > }
> > > > >
> > > > > What's the right way to do this in Cygwin?
> > > >
> > > > I guess it's clear from the context, but I should have said that the
> > > > problem only arises when emacs has to communicate with the subprocess
> > > > through a tty that is not the controlling tty of emacs.  So tcgetpgrp()
> > > > doesn't work.
> > >
> > > I am a little confused as to the difference between tcgetpgrp and
> > > TIOCGPGRP given this man page description from "man 4 tty_ioctl" on
> > > linux:
> > >
> > >          TIOCGPGRP pid_t *argp
> > >                 When successful, equivalent to *argp = tcgetpgrp(fd).
> > >                 Get the process group ID of the foreground process group on this terminal.
> > >
> > >          TIOCSPGRP const pid_t *argp
> > >                 Equivalent to tcsetpgrp(fd, *argp).
> > >                 Set the foreground process group ID of this terminal.
> > >
> > > Do you have a simple test case which demonstrates the difference between
> > > the calls?  It seems odd that TIOCGPGRP would allow more access to a tty
> > > than tcgetpgrp.
> >
> > The difference is that, according to POSIX, tcgetpgrp is required to
> > fail unless fd references the controlling terminal of the calling
> > process.  Ironically, Cygwin's tcgetpgrp used to succeed in this
> > situation until Corinna fixed it a year ago:
> >
> >    http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
>
> Yes, I got that but TIOCGPGRP seems to have that same limitation on
> Linux.  That's why I quoted the above man page.

Sorry, I missed the point.  In view of the use of TIOCGPGRP in emacs, 
there must be some unix-like systems (BSD?) where TIOCGPGRP is not 
subject to that limitation.  Is it necessary to keep the limitation in 
Cygwin?  I guess it boils down to how important Linux compatibility is, 
given that POSIX (as far as I know) is silent about TIOCGPGRP.

This is not a big deal from my point of view.  As I said in my first 
message, I have a workaround for the most important uses in emacs.  I 
think it might be more of an issue for mintty.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple