If I was in that context, yes, I would use outside handler threads, but that's because I could probably put the compare-and-swap in one place (or very few).
As of 2.7.0, my bc had 77 places where signals were checked, and I was probably missing a few.
Real-time is different from what I was doing, so it required different techniques.
There is a case for signals in strictly real-time, strictly high-performance, and also strictly realtime+high-performance code.
You have decided to go strictly for high-performance, for your well-argued reasons, and you've abandoned a standard practice for your stated claims, but this isn't just about your code - its about how people can mis-use signals, and in your case you're mis-using signals by not using them.
It is the advice:
>"Yes be very afraid of signals."
.. which feels not entirely appropriate.
So I took a look at the bc code, and I too am terrified of your use of longjmp.
It appears to me you've gotten somewhat smelly code because you didn't find the appropriate datatype for your case, and decided to roll your own scheduling instead. Ouch.
>As of 2.7.0, my bc had 77 places where signals were checked, and I was probably missing a few.
To refactor this to a simple CAS operation to see if the thread should terminate, doesn't seem too unrealistic to me. Only 77 places to drop a macro that does the op - checking only if the signal handler has told your high-performance thread us to stop, hup, die, etc.
Signals are awesome, and work great - obviously - for many, many high-performance applications, and your high-performance, CPU-bound application might feel like the only way you could do it - but you certainly can attain the same performance and still handle signals like a well-behaved application that doesn't have to take big leaps just to stay ahead of the scheduler ..
>Also, I didn't have a scheduler. The point of interrupts is that you don't need a scheduler.
I think where we digress in position is that I do not think you have a good justification for the statement "be scared of signals" because, after all, you are clearly not scared of them and have decided to bend them to your own thoughts on how best to optimize your application, so its sort of ingenuous to hold the position having completely wiped "the standard way to do high-performance signal-handling" from your slate, to put your own special case forward by example. You're clearly not scared of them.
I'm calling you out on it because signals are absolutely not scary, but maybe talking about them with other experts can be.
Your case is more an example of how unscary signals are - but you've opted for longjmp()'s (which are, imho as a systems programmer, a far more cromulant fear) in your code as a solution to a problem which I don't think is really typical.
Thus, not really scary at all.
Well, it was a fun read of some code, and thanks for bc anyway.
If I was in that context, yes, I would use outside handler threads, but that's because I could probably put the compare-and-swap in one place (or very few).
As of 2.7.0, my bc had 77 places where signals were checked, and I was probably missing a few.
Real-time is different from what I was doing, so it required different techniques.