5 ms·

I think signals are a "poor mans" implementation of threads and queues. They didn't have threads and queues back in the 70'ies, so they resorted to an ugly hac

I think signals are a "poor mans" implementation of threads and queues. They didn't have threads and queues back in the 70'ies, so they resorted to an ugly hack. Ditto with interruptable system calls. It's somewhat like the interrupt-level callbacks classic MacOS (version 1-9) had for network and file i/o. They too didn't have threads back then, so interrupt-callbacks was the only way to avoid blocking calls which would make the UI hang while waiting for network requests.

pvg 10y ago
I'm pretty sure they had threads and queues in the 70s. Or they wouldn't have bothered inventing primitives like semaphores in the 60s.
- deleted 10y ago
  [deleted]
- silvestrov 10y ago
  No, threads is a rather late addition to unix. It came in the 90'ies. E.g. Sun Solaris got thread support in 1993. HP/UX got kerner threads in 1997.
mturmon 10y ago
This is an interesting perspective. I think of signals the other way around -- that they came out of people realizing how useful hardware interrupts could be in allowing devices to talk to the kernel, so they engineered a similar affordance (signals) to allow the kernel to talk to processes. In the case of hardware interrupts (like for old keyboards), if you didn't grab that character off the hardware right away, it would vanish, or another one would take its place. As long as you were fast, it worked. Same with signals. As long as you don't try to do too much in the handler, it works. In other words, it was designed to be "good enough" if used properly (just like all hardware).
adrianratnapala 10y ago
...so interrupt-callbacks was the only way to avoid blocking calls I don't know how early MacOS works, but on Unix its not the _only_ way: that's what poll(), select() and the like are for. And while threads their uses, they don't really change this aspect. Eventually the thread must report a result, and the best way to do that is to report into to some queue that gets polled somewhere.
- cturner 10y ago
  "on Unix its not the _only_ way" Options were more limited in early unix. Use of signals as an adhoc IPC mechanism predates BSD sockets api (1983). Poll has something to do with SysV, so would have been later. There may have been other IPC mechanisms that were dropped before modern unix (but presumably dropped for good reasons). Art of Unix Programming refers to one called mx.

pvg 10y ago

I'm pretty sure they had threads and queues in the 70s. Or they wouldn't have bothered inventing primitives like semaphores in the 60s.

deleted 10y ago
[deleted]
silvestrov 10y ago
No, threads is a rather late addition to unix. It came in the 90'ies. E.g. Sun Solaris got thread support in 1993. HP/UX got kerner threads in 1997.

mturmon 10y ago

This is an interesting perspective. I think of signals the other way around -- that they came out of people realizing how useful hardware interrupts could be in allowing devices to talk to the kernel, so they engineered a similar affordance (signals) to allow the kernel to talk to processes. In the case of hardware interrupts (like for old keyboards), if you didn't grab that character off the hardware right away, it would vanish, or another one would take its place. As long as you were fast, it worked. Same with signals. As long as you don't try to do too much in the handler, it works. In other words, it was designed to be "good enough" if used properly (just like all hardware).

adrianratnapala 10y ago

...so interrupt-callbacks was the only way to avoid blocking calls I don't know how early MacOS works, but on Unix its not the _only_ way: that's what poll(), select() and the like are for. And while threads their uses, they don't really change this aspect. Eventually the thread must report a result, and the best way to do that is to report into to some queue that gets polled somewhere.

cturner 10y ago
"on Unix its not the _only_ way" Options were more limited in early unix. Use of signals as an adhoc IPC mechanism predates BSD sockets api (1983). Poll has something to do with SysV, so would have been later. There may have been other IPC mechanisms that were dropped before modern unix (but presumably dropped for good reasons). Art of Unix Programming refers to one called mx.