[Boost-users] Asynchronous signals library

[Edward Diener]

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 ?

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Anthony Foiani]

Edward Diener <eldi...@tropicsoft.com> 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.

[Edward Diener]

On 5/26/2012 1:54 AM, Anthony Foiani wrote:
> Edward Diener<eldi...@tropicsoft.com> 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)'.

Sorry, by 'signals(2)' I meant 'Bopst signals or signals2 libraries'.

[Ivan Le Lann]

----- Mail original -----
> De: "Edward Diener" <eldi...@tropicsoft.com>
> À: boost...@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

[Edward Diener]

On 5/28/2012 4:31 AM, Ivan Le Lann wrote:
>
>
> ----- Mail original -----
>> De: "Edward Diener"<eldi...@tropicsoft.com>
>> À: boost...@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.

That is a really interesting idea. Thanks !