20,741
edits
Modernizing FlightGear Scripting: Difference between revisions
Jump to navigation
Jump to search
Modernizing FlightGear Scripting (view source)
Revision as of 10:51, 9 October 2016
, 9 October 2016→Implementation Strategy
| Line 458: | Line 458: | ||
|date = Oct 7th, 2016 | |date = Oct 7th, 2016 | ||
|added = Oct 7th, 2016 | |added = Oct 7th, 2016 | ||
|script_version = 0.40 | |||
}}</ref> | |||
We should probably implement multi-processing or multi-threading using message passing, and mirrors of the property tree. (And hence no concerns about locking at all!) | |||
Rough design is: | |||
* main thread has existing property tree | |||
* other threads have read only copy (mirror) of their parts property tree (subscription model, so only the parts they have requested) | |||
* new code synchronies property changes from the master to the copies once per frame or some other interval | |||
* other threads can ONLY interact with the main thread via the command API (which can be serialised into messages, and queued to be passed back to the main thread). | |||
(so on a non-main thread, when you try and do ‘setValue’ on a property, we queue a ‘property-assign’ command and send it to the main thread) | |||
The good thing about this is it works with multi-threading but also with multi-processing (using shared memory, named pipes or Unix domain sockets) so we could e.g. have the main simulation logic run as a separate process from multiple viewers. But we can run as a single process with threads using local memory to implement the message-passing of commands and have very little overhead. (Even though overhead of shared memory or Unix sockets will be virtually zero also). And of course if we use TCP sockets this is really distributable over a LAN (but not a WAN I guess) James intends to prototype this using some of the existing Network/IO protocols, eg the [[Telnet usage|telnet]] one and a binary equivalent. | |||
James mentioned it can be done with only small changes to SGPropertyNode, initially. What he would then suggest is, we implement scripting options such as Python by implementing a small library in that language, which talks the message-passing protocol. | |||
Again for a proof-of-concept this could be done using the [[Telnet usage|telnet]] or props protocols, and as more performance is needed we using a binary protocol and shared memory. | |||
We still need the discussion about which language is mandatory but using a different language for an optional component won’t impact the core code at all. | |||
Note this is totally orthogonal to the HLA work - HLA is a much higher level abstraction, we cannot use it to mirror the property tree. James' goal above is to explore a low-cost route to exploiting multi-core CPUs with the current codebase, in a way which keeps existing code working and fixes the locking / race bugs we already have with OSG touching properties at the same time as the main thread. So, in terms of any scripting system, James would suggest to think about it along these lines, and especially any problems you can foresee, because it’s much better that we agree what is practical and move together, than have three different attempts to fix or work-around the lack of locking in the property tree.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/34790212/ | |||
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded | |||
Python interpreter as a FlightGear subsystem. </nowiki> | |||
|author = <nowiki> James Turner </nowiki> | |||
|date = Jan 23rd, 2016 | |||
|added = Jan 23rd, 2016 | |||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||