Having stack traces on critical faults is an "enterprisey" feature that I
like. It would be nice if swift allowed customization of what happened on
a trap (like array out of bounds), so it dumped the thread's stack trace to
stderr before exiting.
I can simulate the desired behavior by installing a signal handler for
SIGILL, and launch a script that fires up a debugger which attaches to the
process and dumps the stack trace(s) before terminating it.
It's just a small pain to build and link the C code to each swift project.
So my question is, can I use pure swift code for the signal handling
instead of that C shim.
1) Does swift on linux support an atomic_fetch_add() equivalent out of the
box (or some other signal-safe serialization)
2) Any other concerns using swift code in a signal handler. I'd just be
using Glibc system calls, and any char data would be pre-allocated.
You should use the C code. Signal handlers are allowed to do almost nothing. Neither the Swift runtime nor the code generated by the Swift compiler promise to be signal-safe.
ยทยทยท
On Dec 22, 2015, at 4:32 PM, Karl Pickett via swift-users <swift-users@swift.org> wrote:
Having stack traces on critical faults is an "enterprisey" feature that I like. It would be nice if swift allowed customization of what happened on a trap (like array out of bounds), so it dumped the thread's stack trace to stderr before exiting.
I can simulate the desired behavior by installing a signal handler for SIGILL, and launch a script that fires up a debugger which attaches to the process and dumps the stack trace(s) before terminating it.
It's just a small pain to build and link the C code to each swift project. So my question is, can I use pure swift code for the signal handling instead of that C shim.
1) Does swift on linux support an atomic_fetch_add() equivalent out of the box (or some other signal-safe serialization)
2) Any other concerns using swift code in a signal handler. I'd just be using Glibc system calls, and any char data would be pre-allocated.