[signals] thread_safe_signals release
I've uploaded a tarball with my thread-safe signals implementation to the boost vault, so it is easier for people to try out: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename... The tarball also has a modified version of the signals html docs, that should be sufficient for people to figure out what changes have been made to the api. -- Frank
I've put up a minimal web page for thread_safe_signals: http://www.comedi.org/projects/thread_safe_signals/doxygen/index.html with links for the tarball download and the html documentation. Also, there's a new tarball that fixes a couple bugs with multiple-definitions when linking. -- Frank
On 3/8/07, Frank Mori Hess <frank.hess@nist.gov> wrote:
I've put up a minimal web page for thread_safe_signals:
http://www.comedi.org/projects/thread_safe_signals/doxygen/index.html
with links for the tarball download and the html documentation. Also, there's a new tarball that fixes a couple bugs with multiple-definitions when linking.
-- Frank
Thanks for posting that! I downloaded the tarball and added it to my boost tree. My first question is regarding the file structure - currently, there are conflicts between files of the old signals library and thread_safe_signals. I am trying to adapt the signal networks / signal flow library to be compatible with both signals and your thread_safe_signals, and it would be helpful if both signal libraries could co-exist in the same file system. To allow this, I modified last_value.hpp, signals/connection.hpp and signals/slot.hpp as follows: #ifdef BOOST_USE_THREAD_SAFE_SIGNALS ... your new code ... #else ... old code ... In finalizing your library, would it be possible for you to add some mechanism like this to allow the two signal libraries to coexist on the same file system? Also, what are your plans for thread_safe_signals? Will signals be replaced with thread_safe_signals or be a separate addition to the library? When I tried to build my code using thread_safe_signals, I get an error using MSVC8 and boost_1_33_1: \boost\thread_safe_signals\connection.hpp(123) : error C2039: 'lock' : is not a member of 'boost::function<Signature>' Should I be using the CVS version of boost? Thanks, Stjepan
On Thursday 08 March 2007 17:52 pm, Stjepan Rajko wrote:
Thanks for posting that! I downloaded the tarball and added it to my boost tree. My first question is regarding the file structure - currently, there are conflicts between files of the old signals library and thread_safe_signals. I am trying to adapt the signal networks / signal flow library to be compatible with both signals and your thread_safe_signals, and it would be helpful if both signal libraries could co-exist in the same file system. To allow this, I modified last_value.hpp, signals/connection.hpp and signals/slot.hpp as follows:
#ifdef BOOST_USE_THREAD_SAFE_SIGNALS ... your new code ... #else ... old code ...
In finalizing your library, would it be possible for you to add some mechanism like this to allow the two signal libraries to coexist on the same file system?
I intended for thread_safe_signals to be unpacked in a separate directory from your full boost installation. You could then choose to use it (or not) by including the path to thread_safe_signals in your include path, before the path to the full boost installation.
Also, what are your plans for thread_safe_signals? Will signals be replaced with thread_safe_signals or be a separate addition to the library?
It's intended to be a replacement. Douglas Gregor indicated he was fine with replacing the current version of signals with a thread-safe version 2, if the interface wasn't changed too much. He hasn't commented specifically on the interface changes we have made though. Timmo Stange also has another thread-safe implementation he's been working on in parallel, which is similar in interface to thread_safe_signals, but uses much more of the original Boost.Signals codebase.
When I tried to build my code using thread_safe_signals, I get an error using MSVC8 and boost_1_33_1:
\boost\thread_safe_signals\connection.hpp(123) : error C2039: 'lock' : is not a member of 'boost::function<Signature>'
Thanks for the bug report, I don't have any Microsoft compilers. Would you try the attached patch?
Should I be using the CVS version of boost?
No, anything 1.33.0 or newer should be fine on Windows. I usually use 1.32.0 on Linux. -- Frank
On Fri, 2007-03-09 at 09:46 -0500, Frank Mori Hess wrote:
It's intended to be a replacement. Douglas Gregor indicated he was fine with replacing the current version of signals with a thread-safe version 2, if the interface wasn't changed too much. He hasn't commented specifically on the interface changes we have made though.
Yes, we should be looking to make the existing Signals thread-safe or replace it entirely, and we expect that some interface changes will be necessary. I'll take a look and send some comments when time permits... Cheers, Doug
Frank Mori Hess wrote:
Timmo Stange also has another thread-safe implementation he's been working on in parallel, which is similar in interface to thread_safe_signals, but uses much more of the original Boost.Signals codebase.
I actually think there's not much common code with the original Signals in my implementation anymore, but I used it heavily for reference to avoid incompatibility surprises. It also does not comply with the recent interface changes we discussed as I simply did not have any time to work on it. I'm still planning to get a working version some time soon though. I will also look at your current implementation more closely then. Do you have any threaded testing code you could share, btw? I've thought about modifying the random signals system, but with the book- keeping it would become heavily serialized and thus not very useful. Regards Timmo Stange
On Friday 09 March 2007 16:34 pm, Timmo Stange wrote:
Do you have any threaded testing code you could share, btw? I've thought about modifying the random signals system, but with the book- keeping it would become heavily serialized and thus not very useful.
Unfortunately, no. There is a little benchmark program boost-sandbox/libs/thread_safe_signals/test/invocation_test.cpp which can run invocations in multiple threads, but it doesn't really test anything aside from speed. -- Frank
Frank,
I intended for thread_safe_signals to be unpacked in a separate directory from your full boost installation. You could then choose to use it (or not) by including the path to thread_safe_signals in your include path, before the path to the full boost installation.
Good call - I switched to doing that. I can detect which version is being used by looking at what got #defined.
Thanks for the bug report, I don't have any Microsoft compilers. Would you try the attached patch?
Worked. Thanks! After building with the latest version, I got some warnings (and an error that only appeared after some time, not sure what triggered it). Patches for the warning and error included, although I'm not sure I handled the error fix the best way. I am still a little bit patch challenged, so if I made / sent the patches wrong somehow please let me know! Warning 1 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\thread_safe_signals\slot_base.hpp 56 Warning 2 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\thread_safe_signals\connection.hpp 125 Warning 3 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\thread_safe_signals\connection.hpp 125 Warning 4 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\thread_safe_signals\connection.hpp 125 Warning 5 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\thread_safe_signals\connection.hpp 125 Warning 6 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\thread_safe_signals\connection.hpp 125 Warning 7 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\last_value.hpp 84 Warning 8 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\last_value.hpp 84 Warning 9 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\last_value.hpp 84 Warning 10 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\last_value.hpp 58 Warning 11 warning C4101: 'err' : unreferenced local variable c:\development\ame\cpp\include\thread_safe_signals\boost\last_value.hpp 84 Error 12 error C2440: '<function-style-cast>' : cannot convert from 'const char [40]' to 'boost::no_slots_error' c:\development\ame\cpp\include\thread_safe_signals\boost\last_value.hpp 31 Cheers, Stjepan
On Sunday 18 March 2007 05:50 pm, Stjepan Rajko wrote:
After building with the latest version, I got some warnings (and an error that only appeared after some time, not sure what triggered it). Patches for the warning and error included, although I'm not sure I handled the error fix the best way.
Thanks, I've applied your patches to the sandbox cvs. -- Frank
participants (5)
-
Douglas Gregor -
Frank Mori Hess -
Frank Mori Hess -
Stjepan Rajko -
Timmo Stange