Hi Joel,
On 29.09.2016 16:25, Joel Ostraat wrote:
I chatted with Bill Deegan on IRC yesterday. He encouraged me to file a bug
report
(http://scons.tigris.org/issues/show_bug.cgi?id=3033) and ask how this might be
fixed. To reiterate my thoughts and questions from
the bug report:
Looking into it a little, I think that SCons.Node.FS.File.executor should never
be None. The uses of get_executor() prior to this
change seem to expect it to return either a valid Executor object, or raise an
exception leaving the executor attribute non-existent.
I was able to prevent the problem by changing the line
https://bitbucket.org/scons/scons/commits/a8570fab2b7b2f3f1ce520528908904b9584e1f9#Lsrc/engine/SCons/Node/FS.pyT2786
to
self.reset_executor() and removing a few other checks for "self.executor is
None" also added in that commit. But I don't know if
that's the right solution.
Perhaps there is some extra meaning meant to be conveyed when that executor
attribute is be None. If that's true, then there are
many other places where the return value of get_executor() should be checked
against None.
welcome to the dev list! The log message (as well as the various
comments/documentation around the changes) of the commit
a8570fab2b7b that you mention in your bug report, hint at what the change tries to accomplish. The executor is reset to "None",
after building the target or finding that it's up-to-date, such that the garbage collector can free its memory. This is important in
large projects (100000+ files) where the amount of memory used by the Executor objects reach a significant percentage and help to
drive the whole build process into swapping much sooner.
I've been using SCons for a while, but know very little about the internals of
SCons. Any direction on how to fix this would be
appreciated.
If you see/can identify several other places and situations where a valid executor seems to be expected, they probably need a guard
against "executor == None". Would you be able to have a look at that and try to come up with a pull request? That would be awesome.
Best regards,
Dirk
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
