| > I know. That doesn't really excuse the suckiness of asynchronous signals. It's quite simply stupid to have operating system facilities that are as limited as actual hardware interfaces. With signals, you're supposed to write code like your computer is a Super Nintendo or something. This isn't really comprehensible. The issues with signals are presented as something that makes them "broken". Are you claiming that hardware interrupts are broken? > Signals suck as a notification system too, simply because there is no queue. You are conflating two different things. A queue is for messages. An interrupt is for notification. This is how hardware interrupts work. Some work arrives somewhere (in a queue, a register, some memory, whatever), so an interrupt is raised to notify that work is pending. Likewise signals can be and are associated with queues or messages or pending events that can be interrogated after the notification that there is work. > You're supposed to be notified by a signal when a child process exits but the system can actually lose that information forever in certain conditions which means it is literally impossible to build truly correct software, best you get is good enough. You also get a signal when you write to a pipe with no readers or when the terminal is resized, making it that much more of a pain to deal with that stuff. I won't go into every type of signal. There are some that are not defined in a way that can be used by what people want to use them for. That's not a problem with "signals", it's a problem with a particular signal or lack of additional interfaces around that to provide what is required. > The paper mentions several concrete examples in wide use right now even in consumer machines. Systems on a chip with accelerators, GPUs... For the most part not heterogeneous. Masters that have access to host address translation services (like cache coherent GPUs or FPGAs on some busses, like nvlink or CXL with ATS) have equal ability to access the entire process memory space. And fork doesn't look really different from many other operations on an address space from the point of view of an MMU whether it's on the core or associated with an accelerator -- all it is is changing memory protections and taking page faults, the same kind of COW is done with private writable mappings, or page deduplication, for example. They really are just handwaving up things that nobody actually uses. |