Re: [Flightgear-devel] WIN32 threaded binary
Erik Hofman writes:
Norman Vine wrote:
but FGFS still won't exit with out a 'ctrl-c' or other forced
sig quit with the existing static FGTileManager whereas
it exits with a dynamically allocated one that automagically
calls its destructor at exit time
I can't check this one myself because the new ATC code needs some more
attention fro IRIX, but could you give this patch a try?
In theory it should work, but ...
inline
SGThread::~SGThread()
{
+// Make sure the thread is cancelled at exit.
+pthread_kill(tid, SIGKILL);
}
Good try but ...
This should work with Cygwin but it won't work with native Win32
because native Win32 does not implement signals.
I think the easiest way todo this portably is to rely on the C++ 'dtor'
to bring the threads down. i.e if the threads 'belong' to an allocated
class then when the class destructor is called the thread will be destoyed.
This seems to work well with both Cygwin and MingW32
and I see no reason why it shouldn't just work everywhere
Also allocating the tile_manager(s) rather then having one global one
is probably a good idea too in that it will allow us to have a different
tile_manager for different locations.
i.e static FGLocations like the tower_view could have their own set of
tiles then.
This is potentially a more efficient approach and would solve some of
the problems assosciated in controlling more then one FDM within a
single instance of FGFS.
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman Vine wrote: Erik Hofman writes: Good try but ... This should work with Cygwin but it won't work with native Win32 because native Win32 does not implement signals. Erm, you are right off course. I think the easiest way todo this portably is to rely on the C++ 'dtor' to bring the threads down. i.e if the threads 'belong' to an allocated class then when the class destructor is called the thread will be destoyed. This seems to work well with both Cygwin and MingW32 and I see no reason why it shouldn't just work everywhere Also allocating the tile_manager(s) rather then having one global one is probably a good idea too in that it will allow us to have a different tile_manager for different locations. i.e static FGLocations like the tower_view could have their own set of tiles then. This is potentially a more efficient approach and would solve some of the problems assosciated in controlling more then one FDM within a single instance of FGFS. It sounds fine to me. Does anybody have any objections? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman Vine wrote: Jonathan Polley writes: I would like to see if this solves a similar problem I have with OS X's threading. I really prefer the threaded tile loader as it gives me a much smoother frame rate. Interesting that this problem exists on OS X also. Could the automatic cleanup of threads at exit() be a Linux extension to Posix threads ??? http://www.opengroup.org/onlinepubs/007908799/xsh/threads.html Well, IRIX doesn't have this problem, so at least it's not not just a Linux extension. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman Vine wrote:
But the question remains how best to get the threaded tile manager
working and 'behaving' under Win32 and OS X.
Does this patch work by any chance?
Erik
--- /home/erik/src/CVS/fgfs/SimGear/simgear/threads/SGThread.cxxSat Sep 7
04:58:20 2002
+++ SimGear/simgear/threads/SGThread.cxxWed Dec 4 21:29:37 2002
@@ -19,18 +19,20 @@
void
SGThread::set_cancel( cancel_t mode )
{
+int oldstate;
+
switch (mode)
{
case CANCEL_DISABLE:
- pthread_setcancelstate( PTHREAD_CANCEL_DISABLE, 0 );
+ pthread_setcancelstate( PTHREAD_CANCEL_DISABLE, oldstate );
break;
case CANCEL_DEFERRED:
- pthread_setcanceltype( PTHREAD_CANCEL_DEFERRED, 0 );
- pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, 0 );
+ pthread_setcanceltype( PTHREAD_CANCEL_DEFERRED, oldstate );
+ pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, oldstate );
break;
case CANCEL_IMMEDIATE:
- pthread_setcanceltype( PTHREAD_CANCEL_ASYNCHRONOUS, 0 );
- pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, 0 );
+ pthread_setcanceltype( PTHREAD_CANCEL_ASYNCHRONOUS, oldstate );
+ pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, oldstate );
break;
default:
break;
Re: [Flightgear-devel] WIN32 threaded binary
Erik Hofman writes: Norman Vine wrote: But the question remains how best to get the threaded tile manager working and 'behaving' under Win32 and OS X. Does this patch work by any chance? It seems to fix a minor problem with my patch i.e. FGFS printed a failed assertion is sgThread at exit and this patch gets rif of that but FGFS still won't exit with out a 'ctrl-c' or other forced sig quit with the existing static FGTileManager whereas it exits with a dynamically allocated one that automagically calls its destructor at exit time Thanks Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
On Wednesday, December 4, 2002, at 03:00 AM, Erik Hofman wrote: Norman Vine wrote: Jonathan Polley writes: I would like to see if this solves a similar problem I have with OS X's threading. I really prefer the threaded tile loader as it gives me a much smoother frame rate. Interesting that this problem exists on OS X also. Could the automatic cleanup of threads at exit() be a Linux extension to Posix threads ??? http://www.opengroup.org/onlinepubs/007908799/xsh/threads.html Well, IRIX doesn't have this problem, so at least it's not not just a Linux extension. Erik Actually, MacOS X has had some known issues with pthreads, although 10.2 is much better than 10.1. Although I can now build with threading, using ESC hangs at the end. If I select the Quit menu item, it shuts down just fine. I would expect that the behavior of exit() is very well defined and, in my case, OS X's implementation is still lacking. I'll try the updates out this weekend. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman Vine wrote: I have placed a MingW32 native win32 fgfs executable compiled from yesterday's CVS files at http://rockfish.net/~nhv/fgfs/fgfs_ming_thread.tgz This uses the threaded tile pager and I have included a pthread.dll that must be kept in the same directory as the executable This will require the CVS version of the base files There is a 'known' problem exiting the program with the pager thread not getting a 'quit' mesage I have updated this tarball to a version that does NOT have a problem exiting. The way I fixed the 'thread not receiving a cancel event' was to make the global_tile_mgr a pointer to an allocated instance of a FGTileMgr and its FGTileLoader member an allocated object also. Then deletiing the global_tile_mgr at exit time automagically destroys the threads :-) This begs the question How do we want to handle 'Singleton Objects' like this The static nature they currently have is I believe a leftover from the pre C++ era My instinct is that all of these should be moved into the fgGlobals class and be allocated objects derived from an abstract Singleton class Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman, Will you be rolling this change into the baseline any time soon? I would like to see if this solves a similar problem I have with OS X's threading. I really prefer the threaded tile loader as it gives me a much smoother frame rate. Thanks, Jonathan Polley On Tuesday, December 3, 2002, at 07:29 PM, Norman Vine wrote: I have updated this tarball to a version that does NOT have a problem exiting. The way I fixed the 'thread not receiving a cancel event' was to make the global_tile_mgr a pointer to an allocated instance of a FGTileMgr and its FGTileLoader member an allocated object also. Then deletiing the global_tile_mgr at exit time automagically destroys the threads :-) This begs the question How do we want to handle 'Singleton Objects' like this The static nature they currently have is I believe a leftover from the pre C++ era My instinct is that all of these should be moved into the fgGlobals class and be allocated objects derived from an abstract Singleton class Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] WIN32 threaded binary
Hi all I have placed a MingW32 native win32 fgfs executable compiled from yesterday's CVS files at http://rockfish.net/~nhv/fgfs/fgfs_ming_thread.tgz This uses the threaded tile pager and I have included a pthread.dll that must be kept in the same directory as the executable This will require the CVS version of the base files There is a 'known' problem exiting the program with the pager thread not getting a 'quit' mesage I just use 'ctrl-c' in the console window and this seems to work This also uses Andy's 3D HUD for the normal HUD and the previous minimal 2D HUD The only other change is I am testing a 'modified' tilemanager and would 'appreciate' feedback on any tile-boundary problems ie wierd crashes, spurious height above ground readings ect Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman, Which pthread library did you use? The RedHat one (http://sources.redhat.com/pthreads-win32/) or something else? Jonathan Polley On Monday, Dec 02, 2002, at 04:57PM, Norman Vine [EMAIL PROTECTED] wrote: Hi all I have placed a MingW32 native win32 fgfs executable compiled from yesterday's CVS files at http://rockfish.net/~nhv/fgfs/fgfs_ming_thread.tgz This uses the threaded tile pager and I have included a pthread.dll that must be kept in the same directory as the executable This will require the CVS version of the base files There is a 'known' problem exiting the program with the pager thread not getting a 'quit' mesage I just use 'ctrl-c' in the console window and this seems to work This also uses Andy's 3D HUD for the normal HUD and the previous minimal 2D HUD The only other change is I am testing a 'modified' tilemanager and would 'appreciate' feedback on any tile-boundary problems ie wierd crashes, spurious height above ground readings ect Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Jonathan Polley writes: Norman, Which pthread library did you use? The RedHat one (http://sources.redhat.com/pthreads-win32/) or something else? Yes that's the one. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Good, that is the one I have at home so I can play with your multi-threaded .exe. On Monday, December 2, 2002, at 05:35 PM, Norman Vine wrote: Jonathan Polley writes: Norman, Which pthread library did you use? The RedHat one (http://sources.redhat.com/pthreads-win32/) or something else? Yes that's the one. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
I loaded the threaded Win32 FlightGear and gave it a try. Aside from the know problem, which is EXACTLY how my Mac works when I build with threading ;), the only thing I noticed was a slight (10% or so) reduction in frame rate and, the to be expected, garbled output on the console. Good work! Jonathan Polley On Monday, December 2, 2002, at 04:57 PM, Norman Vine wrote: Hi all I have placed a MingW32 native win32 fgfs executable compiled from yesterday's CVS files at http://rockfish.net/~nhv/fgfs/fgfs_ming_thread.tgz This uses the threaded tile pager and I have included a pthread.dll that must be kept in the same directory as the executable This will require the CVS version of the base files There is a 'known' problem exiting the program with the pager thread not getting a 'quit' mesage I just use 'ctrl-c' in the console window and this seems to work This also uses Andy's 3D HUD for the normal HUD and the previous minimal 2D HUD The only other change is I am testing a 'modified' tilemanager and would 'appreciate' feedback on any tile-boundary problems ie wierd crashes, spurious height above ground readings ect Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
