Boost logo

Boost :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2008-02-01 12:04:13

Hash: SHA1

Behaviour of standard signal.h / csignal is known
to be different on windows and posix platforms.

While on posix typically there is no provision for
the thread context the signal handler will run, on
windows the operating system delivers signals into
a separate dedicated thread.

This makes it possible e.g. to use locking primitives
without risk for deadlock.

I wrote a little utility that mimics that behavior
on posix platforms by blocking all signals during
application startup and launching a dedicated thread
that has signal handling turned on.

Since every other thread (that has been started after
main) inherits the all-blocking sigmask, there is only
one thread to handle the signals.

The utility also allows a boost function pointer for
the signal handler.

I would be interested if there is believe such a utility
would be worth including to boost. Also I would be
interested on critics and opinions.

A little usage example that would deadlock on posix when
using std signal() instead of reset_signal():

boost::mutex mx;

void foo(int sig)
    std::cout << "foo attempting to lock" << std::endl;
    boost::mutex::scoped_lock lk(mx);
    std::cout << "foo got lock" << std::endl;

int main(int argc, char* argv[])
    reset_signal(SIGINT, foo);
    boost::mutex::scoped_lock lk(mx);
        << "main got lock, holding it now for 10 secs" << std::endl
        << "pressing ctrl-c triggers the handler" << std::endl
    std::cout << "unlocked, waiting another 10 secs" << std::endl;
    std::cout << "main ending" << std::endl;
    return 0;

- --
  _ _ | Roland Schwarz
 |_)(_ | aka. speedsnail
 | \__) | mailto:roland.schwarz_at_[hidden]
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Boost list run by bdawes at, gregod at, cpdaniel at, john at