Mixed Signals (or, Why Hasn’t This Been Solved Yet?)
POSIX signals have a long history and at least a couple unpleasant limitations. For one thing, with some threading implementations (those with fewer processes than threads) you can’t reliably target a specific thread as a signal recipient. However, luckily for me, that is not my problem.
My problem is both organizational and technical. Signal masks are for an entire process, and that means that masking a signal in your code may unintentionally impact code elsewhere in your application that expected signal delivery to work. This could in theory affect any codebase written by more than one person, but it really becomes an issue when your process uses code written by third parties.
We recently did some work to enable Android applications to use our MCAPI library. Most Android developers work with Java, with each application run in its own virtual machine. However, our MCAPI library is “native code” (i.e. C, not Java), and for that Android uses its own C library called “bionic” and its own threading implementation. The first problem is that bionic doesn’t implement one of the POSIX thread APIs:
As it so happens, we use pthreads in MCAPI for internal control messages. When the user de-initializes MCAPI, we need to shut those threads down, and so on Linux we ordinarily use
pthread_cancel(). Since that’s unavailable in an Android environment, we implemented our own by sending a signal to wake our control thread. The thread is typically blocked in the kernel waiting for a hardware interrupt, so a signal causes it to be scheduled again, at which point it notices it should exit. Not a lot of code; tested on Linux and worked great; problem solved. When we ran it on Android though, it did nothing at all.
Remember how signals are process-wide? Well, as it turns out, Dalvik uses some signals for itself, including the signal we chose for MCAPI:
SIGUSR1. When it came time to kill our thread, we sent the signal… but unbeknown to us, Dalvik code elsewhere in the application had masked
SIGUSR1. Our thread never woke up and never exited.
The Solution (?)
The fix? Use
SIGUSR2 instead. Works great; problem solved. Longer term though, there’s no guarantee that Dalvik won’t start using that too, or an application will link with some other library that (like us) tries to use
SIGUSR2. Since there is no standard API to request and reserve signal numbers, conflicts seem inevitable.
So what to do? The best general solution I can come up with is one that embedded software developers should be familiar with: punt the problem to the integrator. The developer who writes the application using our library should be able to configure MCAPI to use an arbitrary signal, which they ensure won’t conflict with the rest of the application and libraries through code inspection. (Sure hope their third-party libraries come with source code.)
That doesn’t feel very satisfying to me either.
- New in Sourcery CodeBench: improved work relationships
- Tracing Summit: hearing from the users
- Introducing OpenMCAPI
- jumping in with both feet
- Who are you writing that for?
- ARM servers: not so fast
- Mixed Signals (or, Why Hasn’t This Been Solved Yet?)
- performance implications of function pointers
- EETimes virtualization article
- December 2013 (1)
- August 2012 (1)
- March 2011 (1)
- September 2010 (1)
- August 2010 (2)
- July 2010 (1)
- June 2010 (1)
- March 2010 (1)