When you get a busy signal, it comes through the same band (using the same bandwidth) as the voice you hoped to hear. This in-band signal is convenient because it appears just where you were listening and you know what to do.
It also ties up a lot of switching equipment and trunk capacity for a rather small bit (
BooleanRepresentation) of information. And it isn't all that easy to interpret when it's a machine placing the call. Finally, in-band signals are subject to spoofing which has been the mechanism of considerable telephone fraud.
Compare these two idioms ...
- while ((ch=getchar()) != EOF) { ... }
- [aStream atEnd] whileFalse: [aCharacter := aStream next. ...]
The former uses an in-band signal for
end-of-input,
the latter sends it through a separate
band. One is easily made atomic, though not idempotent. The other conserves type-space even though it is hardly in short supply.
In
WritingSolidCode by
SteveMaguire, he spends a chapter discussing
InBandSignal(s), and how, especially in the C libraries, they make it easy to write bad code. Two examples from the book:
1) The getchar() function mentioned above. Because of the name, it's easy to think that it returns a
char,
even though it returns an
int
because of the
InBandSignal
2) Memory management functions like
realloc,
which return the
InBandSignal
NULL
which indicates an "unable to complete operation" signal. If a programmer isn't careful, the signal will be ignored, leading to memory leaks, e.g.
pbBuf = realloc(pbBuf, sizeNew);
if (bpBuf != NULL)
/* use the larger buffer */
Modern languages generally use exceptions instead of in band signals.
A more recent example of an
InBandSignal being used (in C) for nefarious purposes are
FormatStringAttacks
CategoryJargon