Re: [Flightgear-devel] network IO issues
On Thu, Mar 4, 2010 at 10:19 PM, John Denker wrote: ... > > The question of asynchronous IO and thread safety must be > dealt with. FGMetar starts a thread of its own, so it > can deal with network IO without blocking the main loop > of FG. I don't entirely understand what plib does, but > whatever it is, it doesn't work right. > > On 02/08/2010 09:18 AM, Erik Hofman wrote: > > >> FlightGear is not thread safe, simply because it uses OpenGL. Parts of > >> it can work with threads though, and some already do. > > The question for today is: > > Is reading and writing the property tree one of the > safe parts? Is a process that does nothing except > read and write the tree always/sometimes/never > thread safe? > > It depends. The "tree" part of the property tree is not thread safe at all. If a node is added to the property tree in one thread while another thread is parsing a path in the property tree to find a value, the second thread can see an outdated / corrupted version of the property tree. New property tree nodes are probably not added that often at runtime, and some code (but not all) keeps pointers directly to the property nodes it cares about. Getting and setting property values are not necessarily atomic operations, particularly where string values are concerned. So all sorts of races are possible there too. There's no global lock on the property tree and no local locks on nodes in the tree either. > I can imagine getting into trouble if somebody sets a > listener on some property, and then calls opengl from > the listener, whereby writing to the property tree > becomes thread-unsafe. Or are all the listener callbacks > somehow carefully serialized? > No, and the callbacks will be run in whatever thread sets the property. OpenGL's thread safety is really neither here nor there. OpenGL calls are restricted to a few places, and certainly can't happen in a general property listener. OpenGL calls could end up running in several different possible threads or even simultaneously if there is more than one graphics context. > > There are lots of ways of serializing the network traffic, > but it would be a shame to do that if not necessary. If > the property tree is thread safe, that makes everything > simpler and better. > > == > > Bottom line: Does anybody know the right way to make > this work? > > Some of us have thrown around the idea of using the property system as general inter-thread communications mechanism, but there's nothing concrete. The approach I've thought of is to double-buffer the values in the property tree, so that readers see a consistent value for each property. The challenge is doing this without duplicating the entire property tree every frame, and also supporting property tree writes by more than one thread. Tim -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] network IO issues
I observe the following. Lots of irrelevant stuff snipped: Setup: fgfs --httpd=5400 & lynx -source -head http://localhost:5400/sim/intl/locale/strings/ Result: Making HTTP connection to localhost:5400 Alert!: Unexpected network read error; connection aborted. WARNING: netBufferChannel: output buffer overflow! = This is 100% reproducible chez moi. I looked at the code, and this result is entirely predictable, given that the page that should have been returned is larger than the buffer the plib wants it to fit in. There seems to be a deep-seated problem in the "design" of plib. I don't see any way of fixing this without making substantial changes in multiple places. Hypotheses that should be considered include a) rewriting httpd.cxx to use SGIOChannel::readline, or b) switching to something new, such as boost::asio tcp::acceptor Hypotheses that should IMHO not be seriously considered include: x) using the Berkeley sockets directly -- notoriously non-portable y) fussing with plib. This would be a lot of work, and would be a dead end anyway. Any day that you can remove a plib dependency is a good day. The boost stuff seems a bit clumsy, but it should be portable, and it is cleaner than the simgear readline (which is what FGMetar uses) which is in turn much much cleaner than the plib stuff. == The question of asynchronous IO and thread safety must be dealt with. FGMetar starts a thread of its own, so it can deal with network IO without blocking the main loop of FG. I don't entirely understand what plib does, but whatever it is, it doesn't work right. On 02/08/2010 09:18 AM, Erik Hofman wrote: >> FlightGear is not thread safe, simply because it uses OpenGL. Parts of >> it can work with threads though, and some already do. The question for today is: Is reading and writing the property tree one of the safe parts? Is a process that does nothing except read and write the tree always/sometimes/never thread safe? I can imagine getting into trouble if somebody sets a listener on some property, and then calls opengl from the listener, whereby writing to the property tree becomes thread-unsafe. Or are all the listener callbacks somehow carefully serialized? There are lots of ways of serializing the network traffic, but it would be a shame to do that if not necessary. If the property tree is thread safe, that makes everything simpler and better. == Bottom line: Does anybody know the right way to make this work? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 47, Issue 4
This looks like an awesome start. I'll step away from the Super Cub project and look forward to flying Emmanuel excellent work. :) -Gary On Thu, Mar 4, 2010 at 2:12 PM, BARANGER Emmanuel wrote: > > Message: 1 > Date: Wed, 3 Mar 2010 07:07:42 + (GMT) > From: Heiko Schulz > Subject: Re: [Flightgear-devel] Aircraft modeling idea/request: Piper > Super Cub > To: FlightGear developers discussions > > Message-ID: <313579.98950...@web23205.mail.ird.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > Hello Curt, > > > > Now here's the thing ... I'd really like a *Super* Cub, not a J3 Cub. So >>ultimate fame and glory is still right there to be plucked off the >tree. > :-) I think the super cub has a bigger engine, wing flaps, and a >bigger > rear seat ... probably a few other things too. I don't know if it >would > make sense to start with the j3 and modify it into a super cub? Or >maybe > there are enough differences that it would make sense to start from >>scratch? > > > My first thought was, that both aircrafts are similar enough. After some > digging in I found out that's not the case. Similar but clearly not the > same. > > Which model you exactly want? The PA18 or the PA18A? > > You could ask helijah, as it makes more sense in my eyes to start from > scratch. > > It is definitly an aircraft that's missing in FlightGear! > One of the most known aircrafts beside the C172! > > Cheers > HHS > > P.S.: I have some nice photos of the PA 18 Super Cup which may help to > model: > http://www.hoerbird.net/galerie/sonstiges/page-0019.htm > http://www.hoerbird.net/galerie/sonstiges/page-0021.htm > http://www.hoerbird.net/galerie/sonstiges/page-0045.htm > http://www.hoerbird.net/galerie/sonstiges/page-0056.htm > > > > > __ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz > gegen Massenmails. > http://mail.yahoo.com > > > > Hi all. OK I have start yesterday. After 1 day, here are the results : > http://helijah.free.fr/pa18-2.png > > Normally it should fly on Saturday afternoon. And you can create new livery > on Saturday night. > > Best regards. Emmanuel > > -- > BARANGER Emmanuel > > http://helijah.free.fr > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 47, Issue 4
Message: 1 Date: Wed, 3 Mar 2010 07:07:42 + (GMT) From: Heiko Schulz Subject: Re: [Flightgear-devel] Aircraft modeling idea/request: Piper Super Cub To: FlightGear developers discussions Message-ID:<313579.98950...@web23205.mail.ird.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Hello Curt, Now here's the thing ... I'd really like a *Super* Cub, not a J3 Cub. So>ultimate fame and glory is still right there to be plucked off the>tree. :-) I think the super cub has a bigger engine, wing flaps, and a>bigger rear seat ... probably a few other things too. I don't know if it>would make sense to start with the j3 and modify it into a super cub? Or>maybe there are enough differences that it would make sense to start from>scratch? My first thought was, that both aircrafts are similar enough. After some digging in I found out that's not the case. Similar but clearly not the same. Which model you exactly want? The PA18 or the PA18A? You could ask helijah, as it makes more sense in my eyes to start from scratch. It is definitly an aircraft that's missing in FlightGear! One of the most known aircrafts beside the C172! Cheers HHS P.S.: I have some nice photos of the PA 18 Super Cup which may help to model: http://www.hoerbird.net/galerie/sonstiges/page-0019.htm http://www.hoerbird.net/galerie/sonstiges/page-0021.htm http://www.hoerbird.net/galerie/sonstiges/page-0045.htm http://www.hoerbird.net/galerie/sonstiges/page-0056.htm __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com Hi all. OK I have start yesterday. After 1 day, here are the results : http://helijah.free.fr/pa18-2.png Normally it should fly on Saturday afternoon. And you can create new livery on Saturday night. Best regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Need some help in setting up two aircrafts in the same instance of FlightGear
Dear FG members, I'm trying to run two FDMs (type- YaSim) in the same instance of FlightGear and operate each of the two using different keys on the keyboard or two joysticks. I've included two aircraft models in the same .ac file. I'm able to animate the control surfaces of the second a/c using XML. But as of now the second a/c mirrors the movement of the first. So how do I make the second a/c to move independently? I'm not well versed in Nasal code, so I'm unable to figure out if this is even possible to execute. In the property tree can I create a sim2 and introduce a duplicate set of properties to control the second aircraft? Is it possible to create another coordinate frame that follows the second aircraft and toggle between the two frames? Hoping to hear from you soon Kavya -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New GUI Font
leee schrieb: > > If anyone can find some high-res pictures of _real_ HUD displays > (and not ones from flight sims, as they're obviously going to be > produced via a raster display) it should be possible to see the > LCD 'dots' (unless they LCD screen uses a ridiculously high > resolution, which doesn't really chime with the requirements for > size and ruggedisation). > > Anyway, a vector type font should be used on older first generation > HUDs for authenticity. > > LeeE There are some low-res pictures of historical visual target displays from 1940 where you see how the numbers and lines appears. One of the problems I have with the creation of the font for the HUD is that in reality there are many different fonts now. A big change came when HUDs started to give more information than only numbers or lines. The old visual standards to display numbers can make problems when you add characters. The first target display numbers looked like what we have for the taxiway signs (FAA AC 150/5345-44*H*). This numbers were drawn by hand and the forms were following important requirements for human readability like significant differences between '2' and '5' or '5' and '6' etc. New HUDs changed the requirements because they contain now also characters. I do not know if the standards have been adapted to this new needs or if there are many different standards? If someone can point me to some recent documents I am very happy. The first generation enclosing characters I see used 'old' numbers and 'new' characters. Some HUDs did not follow any standard and it looks like they used a font as it was set by technology. When you use 'old' standard you will run into problems with readability and differences between 'l' and '1' or 'O' and '0' i.e. I am working on a font now which integrates old and new numbers. This font could be used for simulating 'visual targets displays' like they have been in past and also for modern HUDs. While the standards are not clear (for me) in the modern HUD (you see so many different letterings) I should probably draw a font which FAA will once integrate in a regulation ;-) Thanks - Yves -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
