Path: utzoo!attcan!uunet!munnari!otc!metro!ipso!runx!brucee From: brucee@runx.ips.oz (Bruce Evans) Newsgroups: comp.os.minix Subject: Re: signal handling and printer driver Message-ID: <1756@runx.ips.oz> Date: 25 Sep 88 08:31:59 GMT References: <2410@sultra.UUCP> Reply-To: brucee@runx.OZ (Bruce Evans) Organization: RUNX Un*x Timeshare. Sydney, Australia. Lines: 45 Dermot Tynan writes: >When running ''make'' in the background, I noticed a strange phenomenon. >If, say, I run 'make &', and then type a file; if I hit ^C (or whatever >the SIG_INT character is), make aborts. A quick look at the code showed I think this is fixed in 1.3. Signal handling was cleaned up. I just fixed a number of signal bugs. Try running the command while : ; echo ok; done and hitting SIG_INT a lot of times. The sig_procs counter in the kernel can be messed up in various ways, such as duplicating the signal PENDING flag for a fork, and the signal library routine has races, some fatal. >Barry, I'll see if there is anything obvious about why it won't work with >1.3. Thanks for the new code -- I can now print decent invoices, etc. There shouldn't be so much concern about the differences in 1.3. All it needed to make Barry's driver work in my system was to add the variable int old_state; replace lock() by old_state = lock() replace unlock() or restore() by restore(old_state). The 1.2 driver didn't have the unlock() but Barry's does. Well, it appears to work OK with my clone-80 unbuffered printer, but so did the old driver. I still have some major complaints. (1) I have 2 printer cards, and the driver always uses the wrong one (opposite to DOS). It should just use the word at 0x40:8 (LPT1). (2) When the printer is taken off-line, the printing job is _instantly_ aborted. It should wait forever while I adjust the paper, etc. This would make the driver simpler. (3) The busy waiting is still silly. No chance of getting the delays correct across the spectrum of machines which run Minix. I would eliminate all of the delay loops and some of the support for buffered printers. If the printer is ready as soon as it can be tested after the previous char output, OK, do another one, but limit this somehow. If a buffered printer is detected, it would be better to avoid doing any output at interrupt time, send a message and have the printer task do it. Bruce Evans Internet: brucee@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!brucee