<div dir="ltr">On Fri, Sep 20, 2013 at 3:42 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nick,<div><div><br>
<br>
On 9/20/2013 5:29 PM, Nick Kledzik wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rui,<br>
<br>
I like this in general, but have a few questions.<br>
<br>
On Sep 20, 2013, at 2:30 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. We would instead add a new method nextFile() to LinkingContext, which returns a new file from which Resolver should try to resolve undefined symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver calls nextFile() repeatedly to link until nextFile() returns a null value.<br>



<br>
3. Resolver will notify Linking Context when (A) all undefined symbols are resolved (success), or (B) it detects it's in an infinite loop in which it cannot resolve any symbols anymore (failure). Linking Context will do whatever it thinks appropriate for the event notification.<br>



</blockquote>
How does the Resolver detect an infinite loop?  As in the example below, it is supposed to keep getting a,b,c,a,b,c…    At some point, no more undefines are being fulfilled by a,b,c,a,b,c…, but how does the resolver know that the files are repeating, to know to tell the InputGraph to move on?<br>



</blockquote></div></div>
nextFile could pass the current resolver state at the time when its called, the linkingcontext can return the next file to be processed as below :-<br>
<br>
nextFile(currentResolverState) :-<br>
<br>
a) Returns the next file if the current node is not a group node<br>
b) Returns the next file in the group node, if the current node is a group node and the resolver state states undefined /weak / shared library atoms were added.<br>
c) Returns the start file in the group node, if the resolver state states undefined/weak/shared library atoms were added<br>
d) If the state is unchanged, no symbols were added exit the group and move to the next node.<br></blockquote><div><br></div><div>So you prefer detecting loop in Linking Context based on the information it's passed by Resolver, over letting Resolver to do that? Not sure if we want the additional information sorted by atom type, but that way should work too.</div>


</div></div></div>