Edward Diener writes:

Is there any Boost library, based on the function prototyping methods of signals(2), in which the signals are handled asynchronously ?

Within Boost, I see Thread and ASIO as the primary methods of working asynchronously. (There's also Coroutine, maybe a few more; I haven't kept up with the latest additions.) As for hooking up to Unix-level signals, some platforms provide methods for mapping signals onto file descriptors. On Linux, see 'signalfd(2)'. If you don't have that, a back up method is to start a thread that does nothing but wait for signals; when a signal is caught by that thread, it sends some sort of notification through a file descriptor (e.g., using 'pipe(2)' before creating the thread). The other end of that pipe is now a file descriptor that generates read events when a signal is caught. Once you have that file descriptor, you can use it with ASIO or with raw system calls. (Or in threads, if you have one thread that does a select/poll loop then dispatches to worker threads.) Does that answer your question, or did I totally misunderstand it? :) Happy hacking, t.

----- Mail original -----

De: "Edward Diener" À: boost-users@lists.boost.org Envoyé: Samedi 26 Mai 2012 04:56:57 Objet: [Boost-users] Asynchronous signals library

The signals and signals2 library work with signals ( events ) which are handled synchronously. Is there any Boost library, based on the function prototyping methods of signals(2), in which the signals are handled asynchronously ?

see: http://www.boost.org/doc/libs/1_49_0/doc/html/signals/s06.html#id3149849 You can write you own combiner to handle the way slots are called. Your combiner could post them in a thread(pool) queue. If you need to report a result from your signal, futures can help. Regards, Ivan