smk@axiom.UUCP (Steven Kramer) (01/11/84)
The signal stuff doesn't work for vnews. I put in most of the fixes that came over the net on our vnews, but the signal stuff is off, especially on the ^Z. (It doesn't stop, but infinitely loops redrawing the screen). I'd appreciate the mods to make it to 4.2. Also, the follow and reply shell scripts pass 2 arguments to the editor in the version we have. Why is that? Does anyone have the correct shell scripts? (I didn't change it to what I thought because I don't understand what was trying to be done.) Much appreciated for any help. -- --steve kramer {allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP) linus!axiom!smk@mitre-bedford (MIL)
mark@cbosgd.UUCP (01/12/84)
Fixing news for 4.2BSD is nontrivial. It involves using setjmp/longjmp and setting a flag so that the longjmp will only be done when there is something ready to catch it. In the meantime, for those of you upgrading to 4.2BSD, here are two things you can do. (1) Use your 4.1BSD binary of readnews. I know this works for a 4.1c binary, and it should work for a 4.1 binary, but I haven't tried it. This works only if you have compatibility mode compiled into the kernel. (2) Create a signal.o file from your old 4.1 libc.a or signal.s, using the 4.1 signal system call number (48). Load with signal.o before libc gets called. This will invoke the 4.1 compatibilty mode signal mechanism in the kernel, and allow you to recompile. I haven't tried this. Mark
guy@rlgvax.UUCP (Guy Harris) (01/13/84)
I believe method 2) (using the old "signal" system call) will also only work if you've compiled compatibility mode into the kernel. (It would solve the great "4.2BSD broke the signal mechanism!" complaint - if you need the old semantics, and can build and use a kernel with the compatibility stuff in it or can get at the source and build one with the old signal call, do it that way.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
john@genrad.UUCP (John Nelson) (01/13/84)
Huh? I found fixing vnews to be pretty trivial! It didn't involve any longjmp/setjmp stuff either! All that was needed was to fiddle with the interrupt mask word (sigblock/sigsetmask) in the SIGTSTP handler routine Maybe I ignore some infrequent race condition, but we've been running it for about two weeks now, and no one has had news die in any new mysterious way! If there is a serious problem, lets see a new release soon!
john@genrad.UUCP (John Nelson) (01/13/84)
A "signal" system call is provided in the standard library for 4.2BSD
(look in section 3C - compatibility library) The differences between
this signal and the old signal are twofold:
1. The signal trapping routine is NOT reset to the default: each handler
must do this explicitly if it is the desired action
2. When the signal handler routine is invoked, the signal MASK bit is
set for that signal (see sigblock/sigsetmask). Additional signals
of the same type that invoked the handler routine will be blocked
until the handler returns (or longjmps, or explicitly resets the mask)
Neither of these incompatibilities is insurmountable if you have the
source code. In fact, in the programs I have been converting to 4.2,
the most common problem is that of a SIGTSTP handler which resets the
terminal parameters, and then kill's itself with SIGTSTP. The routine
below fixes the problem:
tstp_catcher() {
/* I am called to catch tstp and fix the tty mode before stopping */
stty(1, &old_tty_parameters);
signal(SIGTSTP, SIG_DFL);
#ifdef BSD4_2
/* clear SIGTSTP mask bit */
sigsetmask(sigblock(0) & ~(1 << (SIGTSTP-1)));
#endif
kill(0, SIGTSTP);
/* execution resumes here on a SIGCONT */
stty(1, &new_tty_parameters);
}