A guide to Linux signals
linuxvoice.com
A guide to Linux signals
1–10 of 37 posts
Re: A guide to Linux signals
#2Re: A guide to Linux signals
#3Re: A guide to Linux signals
#4Re: A guide to Linux signals
#5Re: A guide to Linux signals
#6Re: A guide to Linux signals
#7Catching signals is a great way of catching nasty bugs in production code. I use them to be able to log information on the cause of an error before the code exits due to some sort of catastrophic bug (e.g. null pointer deference, etc). This also allows you to clean up to clean up temp files, etc. They are much nicer to use than the Windows equivalent.
Strongly disagree. It's hard to make different signals cooperate. Vectored exception handlers in Windows have built-in support for arbitrating between different users.
Re: A guide to Linux signals
#8Catching signals is a great way of catching nasty bugs in production code. I use them to be able to log information on the cause of an error before the code exits due to some sort of catastrophic bug (e.g. null pointer deference, etc). This also allows you to clean up to clean up temp files, etc. They are much nicer to use than the Windows equivalent.
Seriously? You find a system with global events where you must perform your own resource book-keeping to clean up the correct resources nicer than structured exception handling?
Re: A guide to Linux signals
#9Catching signals is a great way of catching nasty bugs in production code. I use them to be able to log information on the cause of an error before the code exits due to some sort of catastrophic bug (e.g. null pointer deference, etc). This also allows you to clean up to clean up temp files, etc. They are much nicer to use than the Windows equivalent.
> They are much nicer to use than the Windows equivalent. Strongly disagree. It's hard to make different signals cooperate. Vectored exception handlers in Windows have built-in support for arbitrating between different users.
Re: A guide to Linux signals
#10Catching signals is a great way of catching nasty bugs in production code. I use them to be able to log information on the cause of an error before the code exits due to some sort of catastrophic bug (e.g. null pointer deference, etc). This also allows you to clean up to clean up temp files, etc. They are much nicer to use than the Windows equivalent.
> They are much nicer to use than the Windows equivalent Seriously? You find a system with global events where you must perform your own resource book-keeping to clean up the correct resources nicer than structured exception handling?