Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: gotos
Message-ID: <11177@mimsy.UUCP>
Date: 22 Apr 88 22:47:22 GMT
References: <1988Apr8.183815.3187@utzoo.uucp> <449@goofy.megatest.UUCP> <1075@maynard.BSW.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 30

>In article <2200@louie.udel.EDU> new@udel.EDU (Darren New) writes:
[pseudocode with `goto handle_key']

In article <1075@maynard.BSW.COM> campbell@maynard.BSW.COM (Larry Campbell)
suggests:

>Use a signal handler.

[code deleted]

Remember also to fcntl(fd, FSETFL, FASYNC) or ioctl(fd, FIOASYNC, &on),
or you will never get a signal.

>This is not only much clearer and easier to read, it's also considerably
>faster.  And doesn't use gotos.

It may be clearer and easier to read, but it is also more dangerous.
Doing I/O in a signal handler is considerably harder than polling for
input at `safe' places.  If the input is to do almost anything useful,
you have created a critical section, which requires blocking and
releasing signals.  The trivial if unclear `goto' variant has been
replaced by a more powerful, more efficient (perhaps*), but much harder
to code correctly, asynchronous variant.

-----
*If the signal blocking and releasing has much overhead, it may be
less efficient than the polling variant.  Fortunately one can cheat
and move the work into the io signal handler, using semaphore variables.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris