20,741
edits
How the Nasal GC works: Difference between revisions
Jump to navigation
Jump to search
→Status (09/2012)
| Line 62: | Line 62: | ||
| date = Mar 26th, 2011 | | date = Mar 26th, 2011 | ||
| added = Mar 26th, 2011 | | added = Mar 26th, 2011 | ||
| script_version = 0.23 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= Running the Nasal GC outside the main thread is already (seemingly) possible but code for it is not in the next branch. I think James fixed the remaining issue a few years back, namely that Nasal/C++ ghost objects must be handed back to the main thread for destruction since they invoke C++-side destructors that touch shared FG state. However, since the Nasal GC (currently) is mutual exclusive to running any Nasal context (using the same heap) this is still not a satisfactory solution once the time needed for a GC approaches the frame duration as the main thread will be blocked waiting for the GC to finish. I've been told this frequently happens for more Nasal heavy use cases, though I have not experienced it on my own ancient (by far GPU-bound) system in my use cases. There are some script use cases that require script code to run in sync with the viewer, e.g. script-based fly by, walk and MP/AI views. For such tightly coupled script code Lua (which, IIRC, offers "real" threads and an incremental GC) or an overhauled incremental and/or concurrent Nasal GC (not a negligible amount of work, though) would seem like options for this type of script code. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/34797127/ | |||
| title = <nowiki>Re: [Flightgear-devel] Designing a thread-safe property tree API | |||
(was Re: A FGPythonSys implementation: ...)</nowiki> | |||
| author = <nowiki>Anders Gidenstam</nowiki> | |||
| date = Jan 26th, 2016 | |||
| added = Jan 26th, 2016 | |||
| script_version = 0.23 | | script_version = 0.23 | ||
}} | }} | ||