Subject: Re: [boost] Proposal for library addition: faster signals/slots, reactor, atomics
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-11-23 22:28:43
On Mon, Nov 23, 2009 at 4:01 PM, Helge Bahmann <hcb_at_[hidden]> wrote:
> Hello everyone
> I have written a small library providing:
> - a (thread-safe) signal/slot implementation
> - poll/timer/reactor implementation
> - atomic operations modelled after the proposed C++0x standard (x86 32/64 bit,
> ppc, alpha, more if someone donates hardware; fallback implementation using
> Currently I am reworking the library to be more closely tied to and better
> reuse services provided by Boost. Obviously, there is considerable functional
> overlap with Boost.Signal/Boost.Signals2 and Boost.Asio, however what sets my
> implementation apart is that it is considerably faster, measurable in both
> synthetic tests and real-world applications (the main way this is achieved is
> through extensive use of atomic operations and carefully designed accessor
> protocols instead of locking, there is a small documentation section
> explaining the technique).
> The signal/slot implementation is thread-safe, with the same guarantees as
> Boost.Signals2, but about 3 times as fast as (thread-unsafe) Boost.Signal (!)
> and about 6 times as fast as (thread-safe) Boost.Signals2.
> The reactor implementation is obviously only suitable for Unix-like systems,
> while the proactor interface provided by Boost.Asio is a nice and portable
> abstraction. However, my reactor implementation is about 2-3 times as fast on
> Unix-like systems for typical network-server-style apps. Moreover I have
> always found Boost.Asio to be difficult to integrate with third party
> libraries (think ALSA or ldap) and frameworks (think Qt, Glib), so other
> developers not interested in portability may also prefer a bare reactor
> If you are interested, I invite you to have a look at:
> Maybe parts of the library might be interesting for Boost? In particular the
> atomic operations could be salvaged and provide a "transitional"
> implementation internal to boost as an interim solution until compiler
> vendors catch up with C++0x, and I would also like to propose the reactor as
> a higher-performance alternative to Boost.Asio (my signal/slot implementation
> lacks combiners and other features provided by Boost.Signals2).
As long as it is all fully compatible with VisualStudio8 (2005 SP1), I
would be quite ecstatic to use this. I use a lot of atomic operations
to make many things lock-less, and having it be a library is useful,
and a reactor design would also very very nice to have, especially
with speed enhancements, and ditto with signal.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk