ian@bilpin.UUCP (Ian Jones) (02/23/89)
I am having a strange problem with GNU Emacs 18.49 on a Macintosh II with A/UX 1.0. The problem arises using Emacs with the 'term' multiple window terminal emulator which is distributed as standard with A/UX. The problem is that after a time, any keyboard input causes Emacs to print IO Signal and expire forthwith. Furthermore, once this error has occurred in a particular window, it is impossible to use Emacs from within that window again without closing the window and re-opening it. Emacs is not the only program which is affected, indeed, any program which reads characters becomes diseased. Common examples are 'vi', 'more' etc. etc. My thoughts on the matter are that the program is receiving SIGIO, which is sent when I/O is possible on a file descriptor in A/UX. Other programs behave differently when receiving this signal (/bin/sh core dumps!) but this is to be expected; if no code has been written to catch this signal, anything could happen! Now the big question - WHY is this happening? Things work correctly until the parent process starts catching SIGIO, and then everything fails from then on. I tried using: fcntl( fileno( stdin ), F_GETOWN, 0 ); which says that all members of the shell's process group will be sent SIGIO, and I tried setting a different process id to receive SIGIO using: fcntl( fileno( stdin ), F_SETOWN, 0 ); But was all to no avail. How do you stop this behaviour? I have no knowledge of how to use this BSD signal, so can somebody please help? Does anybody know what is happening or what to try next? Is it some nasty race condition in Emacs when setting file descriptor parameters? Do any other programs have this behaviour? Am I (or is Emacs) driving the Berkeley signals stuff wrongly? All comments extremely welcome! -- _______________________________________________________________________________ Ian Jones SRL Data || Apple link : UK0001 1 Perren Street London NW5 3ED || UUCP : ian@bilpin.uucp Phone: +44 1 485 6665 || Path : mcvax!ukc!icdoc!bilpin!ian
dwb@sticks.apple.com (David W. Berry) (03/03/89)
In article <1118@bilpin.UUCP> ian@bilpin.UUCP (Ian Jones) writes: >My thoughts on the matter are that the program is receiving SIGIO, which is >sent when I/O is possible on a file descriptor in A/UX. Other programs behave >differently when receiving this signal (/bin/sh core dumps!) but this is to >be expected; if no code has been written to catch this signal, anything >could happen! Well, how about? signal(SIGIO, SIG_IGN);
hugh@hoptoad.uucp (Hugh Daniel) (03/03/89)
There is a bug in A/UX (Even in 1.1 Betas it seems) where every now and then a things get confused and SIGIO is turned on for that tty no matter what you do. I fixed some bugs in the A/UX port of GnuEmacs along with adding a null interupt function to catch the SIGIO. Affixed is my diff from GnuEmacs version 18.52. ||ugh Daniel hugh@toad.com Grasshopper Group, +1 415/668-5998 hugh@xanadu.com 1996 Hayes St. San Francisco CA94117 *** emacs.c.ship Sun Oct 2 18:01:10 1988 --- emacs.c Tue Oct 4 02:08:09 1988 *************** *** 174,179 **** --- 174,186 ---- extern int errno; extern void malloc_warning (); + #ifdef OREO + int eat_sigio(); + + set42sig(); + signal (SIGIO, eat_sigio); + #endif + #ifdef VMS #ifdef LINK_CRTL_SHARE #ifdef SHAREABLE_LIB_BUG *************** *** 181,189 **** #endif /* SHAREABLE_LIB_BUG */ #endif /* LINK_CRTL_SHARE */ - #ifdef OREO - set42sig(); - #endif /* If -map specified, map the data file in */ if (argc > 2 && ! strcmp (argv[1], "-map")) --- 188,193 ---- *************** *** 637,639 **** --- 641,646 ---- DEFVAR_LISP ("kill-emacs-hook", &Vkill_emacs_hook, "Function called, if non-nil, whenever kill-emacs is called."); } + + /* Used to catch SIGIO which AUX1.0 generates erroneusly */ + eat_sigio() {}