top | item 45650660 (no title) bradleybuda | 4 months ago This is awesome. Does POSIX guarantee the order of signal delivery? And I'm dying to see what the bandwidth / throughput of this channel is... discuss order hn newest toast0|4 months ago I don't know if POSIX has a position on signal order. But I'm pretty sure it allows signals to be coallesced... if a process is sent the same signal several times before the handler is invoked, it's in spec to only invoke it once. o11c|4 months ago Real-time signals have guaranteed order: first by number (lowest first, i.e. `SIGRTMIN`), then by the order in which they are sent.Signals are generally the slowest IPC method, unless you're doing something stupid with a different method. bradleybuda|4 months ago Answering both of my questions, from the post: sleep 0.001 # Delay to allow the receiver to process the signal cannonpalms|4 months ago For standard signals--no, but for real-time signals, yes. The latter are still a portability issue, though.
toast0|4 months ago I don't know if POSIX has a position on signal order. But I'm pretty sure it allows signals to be coallesced... if a process is sent the same signal several times before the handler is invoked, it's in spec to only invoke it once.
o11c|4 months ago Real-time signals have guaranteed order: first by number (lowest first, i.e. `SIGRTMIN`), then by the order in which they are sent.Signals are generally the slowest IPC method, unless you're doing something stupid with a different method.
bradleybuda|4 months ago Answering both of my questions, from the post: sleep 0.001 # Delay to allow the receiver to process the signal
cannonpalms|4 months ago For standard signals--no, but for real-time signals, yes. The latter are still a portability issue, though.
toast0|4 months ago
o11c|4 months ago
Signals are generally the slowest IPC method, unless you're doing something stupid with a different method.
bradleybuda|4 months ago
cannonpalms|4 months ago