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