SF 2008 Community awards
Hello, I just received an invitation to nominate a project for SF 2008 Community awards and naturally decided to go for Boost in the category of Best Tool or Utility for Developers. Once in the nomination page I clicked "Search", typed Boost, and now comes the problem: SF locates two different Boost projects: Name: Boost, URL: http://boost.org Name: Boost C++ Libraries, URL: http://sourceforge.net/projects/boost/ Of course both projects are actually the one and only Boost, but I wonder whether we should agree on which one to formally nominate so that our voting force does not get split. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
joaquin@tid.es wrote:
Name: Boost, URL: http://boost.org Name: Boost C++ Libraries, URL: http://sourceforge.net/projects/boost/
Of course both projects are actually the one and only Boost, but I wonder whether we should agree on which one to formally nominate so that our voting force does not get split.
Personally I'd go for boost.org, but <shrug> really. Can we get sf to remove one of them to avoid confusion? John.
John Maddock escribió:
joaquin@tid.es wrote:
Name: Boost, URL: http://boost.org Name: Boost C++ Libraries, URL: http://sourceforge.net/projects/boost/
Of course both projects are actually the one and only Boost, but I wonder whether we should agree on which one to formally nominate so that our voting force does not get split.
Personally I'd go for boost.org, but <shrug> really. Can we get sf to remove one of them to avoid confusion?
I doubt it, this is an automatic search result gotten from some internal database of theirs that I don't think they'd be willing to change for the sake of this small annoyance. In any case, I've opted for boost.org as you suggest. Let's see if we make it to the final!! [BTW, one can nominate the same project for several categories, I selected "Best Project" and "Best Tool or Utility for Developers"]. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hi, I have an application that forks a child process. The child exists only for a little while, (does dup2() calls to redirect stdout/stderr output into pipes and then makes a system() call) and then exits with exit(). However at exit I get an assertion failure in boost.thread library (the assertion happens in the child process) ../boost_1_34_1/libs/thread/src/condition.cpp:351:boost::detail::condition_impl::~condition_impl(): Assertion `res == 0' I wrote a little test application in the hopes of being able to reproduce the problem in smaller scale but naturally it doesn't happen there. Regardless im asking here, whether anyone got any ideas about what might be going wrong and how to go about fixing it. Thanks, - sami ps. here's the code for the test application just in case #include <cstdlib> #include <iostream> #include <boost/thread/condition.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/xtime.hpp> #include <sys/types.h> #include <unistd.h> using namespace std; using namespace boost; int main() { condition cond; mutex m; mutex::scoped_lock l(m); xtime xt; xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; cond.timed_wait(l, xt); pid_t pid = fork(); if (pid != 0) { cout << "parent sleeping...\n"; sleep(10); return 0; } system("echo hello"); cout << "child sleeping...\n"; sleep(15); exit(0); }
Sami Väisänen <sami.vaisanen@ardites.com> writes:
I have an application that forks a child process. The child exists only for a little while, (does dup2() calls to redirect stdout/stderr output into pipes and then makes a system() call) and then exits with exit(). However at exit I get an assertion failure in boost.thread library (the assertion happens in the child process)
../boost_1_34_1/libs/thread/src/condition.cpp:351:boost::detail::condition_impl::~condition_impl(): Assertion `res == 0'
That error indicates that the underlying condition variable couldn't be destroyed properly. Are you sure that your OS correctly clones condition variables when you do a fork? Forking generally doesn't play well with multi-threaded apps anyway, since fork only clones the current thread. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 09 June 2008 06:32 am, Anthony Williams wrote:
Sami Väisänen <sami.vaisanen@ardites.com> writes:
I have an application that forks a child process. The child exists only for a little while, (does dup2() calls to redirect stdout/stderr output into pipes and then makes a system() call) and then exits with exit(). However at exit I get an assertion failure in boost.thread library (the assertion happens in the child process)
../boost_1_34_1/libs/thread/src/condition.cpp:351:boost::detail::conditio n_impl::~condition_impl(): Assertion `res == 0'
That error indicates that the underlying condition variable couldn't be destroyed properly. Are you sure that your OS correctly clones condition variables when you do a fork?
pthreads (at least the version I have) requires mutexes to be re-initialized in the child process after a fork, as mentioned in the pthread_atfork man page. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFITSZh5vihyNWuA4URAllwAJ94J6WzUqLfqMvVY1chbM+DwFX57gCfQDp+ jLsaav0IKluGfDJxQFSJZOs= =/U7Y -----END PGP SIGNATURE-----
On Monday 09 June 2008 06:32 am, Anthony Williams wrote:
Sami Väisänen <sami.vaisanen@ardites.com> writes:
I have an application that forks a child process. The child exists only for a little while, (does dup2() calls to redirect stdout/stderr output into pipes and then makes a system() call) and then exits with exit(). However at exit I get an assertion failure in boost.thread library (the assertion happens in the child process)
../boost_1_34_1/libs/thread/src/condition.cpp:351:boost::detail::conditio
n_impl::~condition_impl(): Assertion `res == 0' That error indicates that the underlying condition variable couldn't be destroyed properly. Are you sure that your OS correctly clones condition variables when you do a fork?
pthreads (at least the version I have) requires mutexes to be re-initialized in the child process after a fork, as mentioned in the pthread_atfork man page. mmh, sounds like this would require me to track the mutexes in the
Frank Mori Hess wrote: parent process in order to be able to re-initialize them in the child process. I guess I must look for alternative ways for solving this problem. (ways that do not involve forking)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sami Väisänen wrote:
n_impl::~condition_impl(): Assertion `res == 0' That error indicates that the underlying condition variable couldn't be destroyed properly. Are you sure that your OS correctly clones condition variables when you do a fork?
../boost_1_34_1/libs/thread/src/condition.cpp:351:boost::detail::conditio pthreads (at least the version I have) requires mutexes to be re-initialized in the child process after a fork, as mentioned in the pthread_atfork man page. mmh, sounds like this would require me to track the mutexes in the parent process in order to be able to re-initialize them in the child process. I guess I must look for alternative ways for solving this problem. (ways that do not involve forking)
You should call _exit() in the child rather than exit(). That should avoid calling any of the usual exit cleanup code (including global destructors). This is generally good advice for whenever you fork() a child process--it should either call exec() or _exit() to avoid calling destructors and other cleanup code twice. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
Jonathan Biggar wrote:
Sami Väisänen wrote:
../boost_1_34_1/libs/thread/src/condition.cpp:351:boost::detail::conditio
n_impl::~condition_impl(): Assertion `res == 0'
That error indicates that the underlying condition variable couldn't be destroyed properly. Are you sure that your OS correctly clones condition variables when you do a fork?
pthreads (at least the version I have) requires mutexes to be re-initialized in the child process after a fork, as mentioned in the pthread_atfork man page.
mmh, sounds like this would require me to track the mutexes in the parent process in order to be able to re-initialize them in the child process. I guess I must look for alternative ways for solving this problem. (ways that do not involve forking)
You should call _exit() in the child rather than exit(). That should avoid calling any of the usual exit cleanup code (including global destructors). This is generally good advice for whenever you fork() a child process--it should either call exec() or _exit() to avoid calling destructors and other cleanup code twice.
This appears to work. Thank you.
participants (6)
-
Anthony Williams -
Frank Mori Hess -
joaquin＠tid.es -
John Maddock -
Jonathan Biggar -
Sami Väisänen