Re: [Flightgear-devel] [patch] Get rid of pthread
Le vendredi 02 mai 2008 à 10:34 +0200, Tim Moore a écrit : This concern is valid, but *every* use of SGMutex removed in Benôit's patch is not actually thread safe now! Static local variables are initialized the first time a function is called. I'm not sure if the proper lesson to take away is that threading is hard, because of subtle issues like this, or if it's easy, because it works even in the presence of such bugs ;) I looked at the code again and, if I understand your warning, there is 2 options: 1/ I'm completely dumb (which is possible ;)) 2/ The old code was not thread safe either. Old code static SGMutex mutex; -- New code static OpenThreads::Mutex mutex; -- As a side note, it seems you already use OpenThreads Mutexes in various places, like in line 939 of simgear/scene/model/animation.cxx: OpenThreads::ScopedLockOpenThreads::Mutex lock(normalizeMutex); or in line 72 of simgear/scene/util/StateAttributeFactory.cxx: OpenThreads::ScopedLockOpenThreads::Mutex lock(_instanceMutex); Would this produce the correct behavior ? Regards, Benoît - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
On Mon, 05 May 2008 20:30:28 +0200 Benoît Laniel [EMAIL PROTECTED] wrote: Le vendredi 02 mai 2008 à 10:34 +0200, Tim Moore a écrit : This concern is valid, but *every* use of SGMutex removed in Benôit's patch is not actually thread safe now! Static local variables are initialized the first time a function is called. I'm not sure if the proper lesson to take away is that threading is hard, because of subtle issues like this, or if it's easy, because it works even in the presence of such bugs ;) I looked at the code again and, if I understand your warning, there is 2 options: 1/ I'm completely dumb (which is possible ;)) 2/ The old code was not thread safe either. 2) is correct. The problem is that a static local variable is only guaranteed to be initialized when a function is first run. If a function has not been called and two threads both call it at the same time then there will be a race to initialized the mutex. Old code static SGMutex mutex; -- New code static OpenThreads::Mutex mutex; -- I'm sorry for the misunderstanding; I didn't mean to imply that your patch was more unsafe than the old code. As a side note, it seems you already use OpenThreads Mutexes in various places, like in line 939 of simgear/scene/model/animation.cxx: OpenThreads::ScopedLockOpenThreads::Mutex lock(normalizeMutex); or in line 72 of simgear/scene/util/StateAttributeFactory.cxx: OpenThreads::ScopedLockOpenThreads::Mutex lock(_instanceMutex); Would this produce the correct behavior ? In both those cases the mutex is a global variable, so it is initialized before the main() function of flightgear is called. So those uses are safe assuming that the functions in which they are located are not called before main(). Tim - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: | On Mon, Apr 28, 2008 at 4:26 PM, Benoît Laniel [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] wrote: | | First, let me thank you all for the great work you've done with FG. | | I started cross-compiling FG using the great fgfs-builder from Ralf and | I have to say that it helped a lot. However, I had to patch the source | code to make it possible. Here is the first one which basically replaces | SGMutex by OpenThreads::Mutex and allows to get rid of pthread. | | | Hi Benoit, | | I just want to jump in and point out that the threading code in | FlightGear and SimGear is very intricate and refined over much time, | blood, sweat, and tears. In addition, any little changes surrounding | the thread management or the contents of threaded code can easily | introduce very subtle bugs that aren't encountered very often and are | tremendously difficult to track down. Not knowing anything about | open-threads, I'm just a little nervous about any changes to | FlightGear's thread system. If OpenThreads has identical functionality This concern is valid, but *every* use of SGMutex removed in Benôit's patch is not actually thread safe now! Static local variables are initialized the first time a function is called. I'm not sure if the proper lesson to take away is that threading is hard, because of subtle issues like this, or if it's easy, because it works even in the presence of such bugs ;) Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIGtIjeDhWHdXrDRURAtpqAKDehf+QDmCZVFJyyYqLXz7w91EzfgCgoyCC fR7HP6vT9Hj2A2ETgZe2+O4= =O1k6 -END PGP SIGNATURE- - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
till busch wrote: salut Benoît, your approach sounds reasonable to me. having all threads-related functionality in OpenThreads is the way to go. imho there is no good reason for maintaining another thread-wrapper in sg. a quick scan shows following classes in sg: class SGThread class SGMutex class SGPthreadCond if they can all be safely replaced with corresponding OpenThread classes that would be fine. i agree with curt's comments, but i'd say: please take the time to carefully compare the code in sg and OpenThreads (like you did below). it is indeed easy to introduce subtle bugs with threading code. I'm generally supportive of this kind of work too. Replacing home-grown code with packages that have a larger user base eases our own development and testing burden. In this specific case Benôit seems to have missed that SGThread is used in flightgear for the metar and voice threads, at least on Linux, so we can't just eliminate SGThread yet, but it does seem safe to eliminate SGMutex. Tim cheers, -till p.s. probably your headline was bad. i think you want to replace sg thread classes with OpenThreads (OpentThreads does use pthread on *nix) On Wednesday 30 April 2008, Benoît Laniel wrote: Perhaps you could begin by explaining the problem you are going to solve, and why your way is better. For windows version of fg, actually there are 2 solutions: - no threads - pthreads-win32 pthreads-win32 is, for me, a hack to ease the porting of *nix code to win32 and may not always be efficient. However, in fg you seem to use openthreads. Since osg is needed for both fg and sg, I thought you could use openthreads in sg too. So I started looking at the threads code in sg and noticed you use pthread for only one thing : SGGuard. From what I understood, the code static SGMutex mutex; SGGuardSGMutex locker(mutex); does this : - SGMutex constructor : calls pthread_mutex_init() - SGGuard constructor : calls SGMutex.lock() (which calls pthread_mutex_lock()) then - SGGuard destructor : calls SGMutex.unlock() (which calls pthread_mutex_unlock()) - SGMutex desctructor : calls pthread_mutex_destroy() Looking at openthreads code, changing SGMutex to OpenThreads::Mutex does this: - OpenThreads::Mutex constructor : calls pthread_mutex_init() - SGGuard constructor : now calls OpenThreads::Mutex.lock() (which calls pthread_mutex_lock()) - SGGuard destructor : now calls OpenThreads::Mutex.unlock() (which calls pthread_mutex_unlock()) - OpenThreads::Mutex destructor : calls pthread_mutex_destroy() However, when compiling for win32, you will have specific win32 threads managment calling EnterCriticalSection(), InterlockedExchange() etc which should be more efficient. So the effects are: - Do not worry about threads portability and always use optimized code from osg which seems a very active project. - Do not worry about threads-enabled/threads-disabled code, just check if openthreads is there. Regards Benoit - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
till busch wrote: salut Benoît, your approach sounds reasonable to me. having all threads-related functionality in OpenThreads is the way to go. imho there is no good reason for maintaining another thread-wrapper in sg. a quick scan shows following classes in sg: class SGThread class SGMutex class SGPthreadCond if they can all be safely replaced with corresponding OpenThread classes that would be fine. i agree with curt's comments, but i'd say: please take the time to carefully compare the code in sg and OpenThreads (like you did below). it is indeed easy to introduce subtle bugs with threading code. I'm generally supportive of this kind of work too. Replacing home-grown code with packages that have a larger user base eases our own development and testing burden. In this specific case Benôit seems to have missed that SGThread is used in flightgear for the metar and voice threads, at least on Linux, so we can't just eliminate SGThread yet, but it does seem safe to eliminate SGMutex. Tim cheers, -till p.s. probably your headline was bad. i think you want to replace sg thread classes with OpenThreads (OpentThreads does use pthread on *nix) On Wednesday 30 April 2008, Benoît Laniel wrote: Perhaps you could begin by explaining the problem you are going to solve, and why your way is better. For windows version of fg, actually there are 2 solutions: - no threads - pthreads-win32 pthreads-win32 is, for me, a hack to ease the porting of *nix code to win32 and may not always be efficient. However, in fg you seem to use openthreads. Since osg is needed for both fg and sg, I thought you could use openthreads in sg too. So I started looking at the threads code in sg and noticed you use pthread for only one thing : SGGuard. From what I understood, the code static SGMutex mutex; SGGuardSGMutex locker(mutex); does this : - SGMutex constructor : calls pthread_mutex_init() - SGGuard constructor : calls SGMutex.lock() (which calls pthread_mutex_lock()) then - SGGuard destructor : calls SGMutex.unlock() (which calls pthread_mutex_unlock()) - SGMutex desctructor : calls pthread_mutex_destroy() Looking at openthreads code, changing SGMutex to OpenThreads::Mutex does this: - OpenThreads::Mutex constructor : calls pthread_mutex_init() - SGGuard constructor : now calls OpenThreads::Mutex.lock() (which calls pthread_mutex_lock()) - SGGuard destructor : now calls OpenThreads::Mutex.unlock() (which calls pthread_mutex_unlock()) - OpenThreads::Mutex destructor : calls pthread_mutex_destroy() However, when compiling for win32, you will have specific win32 threads managment calling EnterCriticalSection(), InterlockedExchange() etc which should be more efficient. So the effects are: - Do not worry about threads portability and always use optimized code from osg which seems a very active project. - Do not worry about threads-enabled/threads-disabled code, just check if openthreads is there. Regards Benoit - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
Perhaps you could begin by explaining the problem you are going to solve, and why your way is better. For windows version of fg, actually there are 2 solutions: - no threads - pthreads-win32 pthreads-win32 is, for me, a hack to ease the porting of *nix code to win32 and may not always be efficient. However, in fg you seem to use openthreads. Since osg is needed for both fg and sg, I thought you could use openthreads in sg too. So I started looking at the threads code in sg and noticed you use pthread for only one thing : SGGuard. From what I understood, the code static SGMutex mutex; SGGuardSGMutex locker(mutex); does this : - SGMutex constructor : calls pthread_mutex_init() - SGGuard constructor : calls SGMutex.lock() (which calls pthread_mutex_lock()) then - SGGuard destructor : calls SGMutex.unlock() (which calls pthread_mutex_unlock()) - SGMutex desctructor : calls pthread_mutex_destroy() Looking at openthreads code, changing SGMutex to OpenThreads::Mutex does this: - OpenThreads::Mutex constructor : calls pthread_mutex_init() - SGGuard constructor : now calls OpenThreads::Mutex.lock() (which calls pthread_mutex_lock()) - SGGuard destructor : now calls OpenThreads::Mutex.unlock() (which calls pthread_mutex_unlock()) - OpenThreads::Mutex destructor : calls pthread_mutex_destroy() However, when compiling for win32, you will have specific win32 threads managment calling EnterCriticalSection(), InterlockedExchange() etc which should be more efficient. So the effects are: - Do not worry about threads portability and always use optimized code from osg which seems a very active project. - Do not worry about threads-enabled/threads-disabled code, just check if openthreads is there. Regards Benoit - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
salut Benoît, your approach sounds reasonable to me. having all threads-related functionality in OpenThreads is the way to go. imho there is no good reason for maintaining another thread-wrapper in sg. a quick scan shows following classes in sg: class SGThread class SGMutex class SGPthreadCond if they can all be safely replaced with corresponding OpenThread classes that would be fine. i agree with curt's comments, but i'd say: please take the time to carefully compare the code in sg and OpenThreads (like you did below). it is indeed easy to introduce subtle bugs with threading code. cheers, -till p.s. probably your headline was bad. i think you want to replace sg thread classes with OpenThreads (OpentThreads does use pthread on *nix) On Wednesday 30 April 2008, Benoît Laniel wrote: Perhaps you could begin by explaining the problem you are going to solve, and why your way is better. For windows version of fg, actually there are 2 solutions: - no threads - pthreads-win32 pthreads-win32 is, for me, a hack to ease the porting of *nix code to win32 and may not always be efficient. However, in fg you seem to use openthreads. Since osg is needed for both fg and sg, I thought you could use openthreads in sg too. So I started looking at the threads code in sg and noticed you use pthread for only one thing : SGGuard. From what I understood, the code static SGMutex mutex; SGGuardSGMutex locker(mutex); does this : - SGMutex constructor : calls pthread_mutex_init() - SGGuard constructor : calls SGMutex.lock() (which calls pthread_mutex_lock()) then - SGGuard destructor : calls SGMutex.unlock() (which calls pthread_mutex_unlock()) - SGMutex desctructor : calls pthread_mutex_destroy() Looking at openthreads code, changing SGMutex to OpenThreads::Mutex does this: - OpenThreads::Mutex constructor : calls pthread_mutex_init() - SGGuard constructor : now calls OpenThreads::Mutex.lock() (which calls pthread_mutex_lock()) - SGGuard destructor : now calls OpenThreads::Mutex.unlock() (which calls pthread_mutex_unlock()) - OpenThreads::Mutex destructor : calls pthread_mutex_destroy() However, when compiling for win32, you will have specific win32 threads managment calling EnterCriticalSection(), InterlockedExchange() etc which should be more efficient. So the effects are: - Do not worry about threads portability and always use optimized code from osg which seems a very active project. - Do not worry about threads-enabled/threads-disabled code, just check if openthreads is there. Regards Benoit - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
- Benoît Laniel a écrit : This is an area where a commit now, test later philosophy could hurt the project because thread related problems can be so nasty to debug. Maybe I should have stated that I didn't know if it was robust. I surely agree with you that this patch should be for testing purpose only. I posted it since I've used it for 2 weeks now and had no problems. Again, I'm no threading expert but I thought some people would be interested by a first draft. Perhaps you could begin by explaining the problem you are going to solve, and why your way is better. -Fred - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [patch] Get rid of pthread
Hi,
First, let me thank you all for the great work you've done with FG.
I started cross-compiling FG using the great fgfs-builder from Ralf and
I have to say that it helped a lot. However, I had to patch the source
code to make it possible. Here is the first one which basically replaces
SGMutex by OpenThreads::Mutex and allows to get rid of pthread.
The other patch is mainly not mixing winsock with winsock2 and changing
ifdefs. Sometimes there is _MSVC_VER, sometimes __MINGW32__ etc... for
the same thing. I didn't want to provide the patch now since I think
there is a better way. ffmpeg began to move all the platform-specific
code in 2 files called os_support.c and os_support.h. I think this way
help people focusing on what's important. Do you think it's a good
idea ? Do you have other ideas ?
Regards
Benoit
Index: configure.ac
===
RCS file: /var/cvs/SimGear-0.3/source/configure.ac,v
retrieving revision 1.107
diff -u -p -r1.107 configure.ac
--- configure.ac 15 Mar 2008 16:33:49 - 1.107
+++ configure.ac 20 Apr 2008 17:01:26 -
@@ -171,22 +171,6 @@ esac
dnl Checks for libraries.
-dnl Thread related checks
-AC_CHECK_HEADER(pthread.h)
-AC_SEARCH_LIBS(pthread_exit, [pthread c_r])
-if test x$ac_cv_header_pthread_h = xyes; then
-CXXFLAGS=$CXXFLAGS -D_REENTRANT
-CFLAGS=$CFLAGS -D_REENTRANT
-
- if test x$ac_cv_search_pthread_exit = x-lc_r; then
-CXXFLAGS=-pthread $CXXFLAGS
-CFLAGS=-pthread $CFLAGS
- fi
-fi
-
-AM_CONDITIONAL(HAVE_THREADS, test x$ac_cv_header_pthread_h = xyes)
-
-thread_LIBS=$LIBS
LIBS=
dnl search for network related libraries
@@ -502,9 +486,3 @@ else
echo Without JPEG Factory support
fi
-if test x$ac_cv_header_pthread_h = xyes; then
- echo Threads: pthread lib found.
-else
- echo Threads: no threads (pthread lib not found.)
-fi
-
Index: simgear/Makefile.am
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/Makefile.am,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile.am
--- simgear/Makefile.am 6 Jan 2007 17:01:58 - 1.18
+++ simgear/Makefile.am 20 Apr 2008 17:01:26 -
@@ -1,9 +1,3 @@
-if HAVE_THREADS
-SGTHREAD_DIR = threads
-else
-SGTHREAD_DIR =
-endif
-
# METAR_DIRS =
METAR_DIRS = environment
@@ -31,7 +25,6 @@ SUBDIRS = \
screen \
serial \
sound \
- $(SGTHREAD_DIR) \
timing
-DIST_SUBDIRS = $(SUBDIRS) compatibility
+DIST_SUBDIRS = $(SUBDIRS) compatibility threads
Index: simgear/scene/model/shadanim.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/model/shadanim.cxx,v
retrieving revision 1.13
diff -u -p -r1.13 shadanim.cxx
--- simgear/scene/model/shadanim.cxx 4 Dec 2007 22:38:41 - 1.13
+++ simgear/scene/model/shadanim.cxx 20 Apr 2008 17:01:26 -
@@ -37,7 +37,7 @@
#include osgUtil/HighlightMapGenerator
#include simgear/scene/util/SGUpdateVisitor.hxx
-#include simgear/threads/SGThread.hxx
+#include OpenThreads/Mutex
#include simgear/threads/SGGuard.hxx
#include simgear/props/condition.hxx
@@ -132,8 +132,8 @@ getOrCreateTextureCubeMap()
if (textureCubeMap.get())
return textureCubeMap.get();
- static SGMutex mutex;
- SGGuardSGMutex locker(mutex);
+ static OpenThreads::Mutex mutex;
+ SGGuardOpenThreads::Mutex locker(mutex);
if (textureCubeMap.get())
return textureCubeMap.get();
@@ -217,8 +217,8 @@ StateSetMap;
// graph: 0 - completely chrome, 1 - completely model texture.
static void create_chrome(osg::Group* group, osg::Texture2D* texture)
{
-static SGMutex mutex;
-SGGuardSGMutex locker(mutex);
+static OpenThreads::Mutex mutex;
+SGGuardOpenThreads::Mutex locker(mutex);
static StateSetMap chromeMap;
osg::StateSet *stateSet;
StateSetMap::iterator iterator = chromeMap.find(texture);
Index: simgear/scene/tgdb/obj.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/obj.cxx,v
retrieving revision 1.33
diff -u -p -r1.33 obj.cxx
--- simgear/scene/tgdb/obj.cxx 24 Mar 2008 21:41:30 - 1.33
+++ simgear/scene/tgdb/obj.cxx 20 Apr 2008 17:01:26 -
@@ -50,8 +50,6 @@
#include simgear/scene/util/SGUpdateVisitor.hxx
#include simgear/scene/util/SGNodeMasks.hxx
#include simgear/scene/util/QuadTreeBuilder.hxx
-#include simgear/threads/SGThread.hxx
-#include simgear/threads/SGGuard.hxx
#include SGTexturedTriangleBin.hxx
#include SGLightBin.hxx
Index: simgear/scene/tgdb/pt_lights.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/pt_lights.cxx,v
retrieving revision 1.14
diff -u -p -r1.14 pt_lights.cxx
--- simgear/scene/tgdb/pt_lights.cxx 21 Dec 2007 06:24:53 - 1.14
+++ simgear/scene/tgdb/pt_lights.cxx 20 Apr 2008 17:01:26 -
@@ -52,7 +52,7 @@
#include simgear/math/sg_random.h
#include
Re: [Flightgear-devel] [patch] Get rid of pthread
On Mon, Apr 28, 2008 at 4:26 PM, Benoît Laniel [EMAIL PROTECTED] wrote: First, let me thank you all for the great work you've done with FG. I started cross-compiling FG using the great fgfs-builder from Ralf and I have to say that it helped a lot. However, I had to patch the source code to make it possible. Here is the first one which basically replaces SGMutex by OpenThreads::Mutex and allows to get rid of pthread. Hi Benoit, I just want to jump in and point out that the threading code in FlightGear and SimGear is very intricate and refined over much time, blood, sweat, and tears. In addition, any little changes surrounding the thread management or the contents of threaded code can easily introduce very subtle bugs that aren't encountered very often and are tremendously difficult to track down. Not knowing anything about open-threads, I'm just a little nervous about any changes to FlightGear's thread system. If OpenThreads has identical functionality to pthreads, perhaps this can be done transparently with no risk to functionality or future robustness ... however, I hope that we proceed very carefully, with much prior discussion and testing. This is an area where a commit now, test later philosophy could hurt the project because thread related problems can be so nasty to debug. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
This is an area where a commit now, test later philosophy could hurt the project because thread related problems can be so nasty to debug. Maybe I should have stated that I didn't know if it was robust. I surely agree with you that this patch should be for testing purpose only. I posted it since I've used it for 2 weeks now and had no problems. Again, I'm no threading expert but I thought some people would be interested by a first draft. Regards, Benoit - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
