Just for the record, I would be pretty strongly opposed to adding a thread
for no particular benefit. In fact I think the threshold of gained benefit
needs to be pretty high to add another thread to the code. Threads might
seem simple at first, but they can hide nasty bugs that are almost
impossible to find. And even if the person submitting the code has
validated everything and it's perfect -- inevitably, someone will come and
make changes somewhere in the code that affect the thread in some subtle way
and we are back to having almost impossible to find bugs. That doesn't mean
we can't make a big mess of non-threaded code too, but threads are 100 times
easier to screw up without realizing it until weeks or months later ... and
when there is a problem, the concurrency of threads can make it extremely
difficult to isolate where the bug actually is.
Regards,
Curt.
On Sun, Apr 10, 2011 at 2:15 PM, Anders Gidenstam wrote:
> On Sun, 10 Apr 2011, Curtis Olson wrote:
>
> > I'm not an expert in nasal garbage collection, but I think the problem is
> > that garbage collection is not something we can divide up into chunks
> (which
> > is essentially what threading would do.) In addition, threading adds a
> lot
> > of potential order dependent bugs. I've got a whole soapbox speech on
> > threading I could deliver which I would summarize as "only if absolutely
> no
> > other solution is viable."
> >
> > In the case of nasal, I believe the garbage collection pass must be done
> in
> > a single atomic step, otherwise it would leave the heap in
> > an inconsistent state and adversely affect the scripts.
>
> There are algorithms for incremental and/or concurrent and/or parallel
> garbage collection out there. They most likely not easy to implement and
> as far as I have seen so far would require (at least for concurrent and
> /or parallel GC) all writes of pointers to the Nasal heap (and possibly
> reads) to be redirected via wrapper functions (also known as
> (GC) read/write barriers).
>
> This will not be an easy task but in my opinion it would be a promising
> option. It might be possible to use a GC module from a GPL:d Java vm or
> similar.
>
> Btw, just running the normal (mutually exclusive) Nasal GC in another
> thread than the main loop is not hard - but since it is mutually exclusive
> to executing Nasal functions it doesn't help much when it comes to
> reducing the worst case latency.
>
> The small changes needed to add a separate GC thread are available here:
> http://www.gidenstam.org/FlightGear/misc/test/sg-gc-2.diff
> http://www.gidenstam.org/FlightGear/misc/test/fg-gc-1.diff
>
> Cheers,
>
> Anders
> --
> ---------------------------------------------------------------------------
> Anders Gidenstam
> WWW: http://www.gidenstam.org/FlightGear/
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://gallinazo.flightgear.org<http://www.flightgear.org/blogs/category/personal/curt/>
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
