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

Subject: [boost] Proposal for library addition: faster signals/slots, reactor, atomics
From: Helge Bahmann (hcb_at_[hidden])
Date: 2009-11-23 18:01:53

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).

Best regards
Helge Bahmann