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