Re: [boost] Proposal for library addition: faster signals/slots, reactor, atomics

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
> locks)
>
> 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
> implementation.
>
> If you are interested, I invite you to have a look at:
>
> http://www.chaoticmind.net/~hcb/projects/libtscb
>
> 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.