<div dir="ltr"><span class="im"><div>> The problem is that most of the time is spent throughout various
functions of Sema in clang, so the only way I see is to have every
function in Sema check for abortion, which sounds like it would horribly
clutter the code...<br><br></div></span>I don't think it needs to be
that extreme. Once every 100ms would be sufficient for my purposes
which would drastically reduce the number of checks needed. My own
profiles are also showing a fair amount of time in the Lex code as
well. I'm still learning the code but I suspect it would be feasible to
check in-between major phases.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 2:27 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><span class="">On Tue Jan 13 2015 at 11:18:38 AM John Sully <<a href="mailto:john@csquare.ca" target="_blank">john@csquare.ca</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'm pretty confident there is no current way to do it, so this week I'll start on my own implementation. For reasons I don't quite understand libclang likes to spawn jobs onto seperate threads (and therefore ignores my thread priorities...) which will make this somewhat more difficult.<br><br></div>I think the sanest way is to pass a bool FCheckAbort() style function pointer as an optional parameter to jobs which may run a long time. I'll have to do some work to marshal this across thread boundaries. Either that or remove the spawned thread entirely.<br></div></blockquote><div><br></div></span><div>The problem is that most of the time is spent throughout various functions of Sema in clang, so the only way I see is to have every function in Sema check for abortion, which sounds like it would horribly clutter the code...</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 12, 2015 at 11:41 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll add my +1 to it being unfortunate that libclang operations cannot be canceled (living in a code base where some TUs take > 30 seconds to parse).<div><div><br><br><div class="gmail_quote">On Tue Jan 13 2015 at 3:38:51 AM John Sully <<a href="mailto:john@csquare.ca" target="_blank">john@csquare.ca</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Jonathan,<br><br>I don't understand how std::future::wait_for
would allow me to cancel a running libclang operation.<br><br></div>I'm not asking how to do this asynchronously - I
already have that working. I need a way to stop performing work when
the results become obsolete. I could always
shutdown the thread its on but that would leave things in an undefined
state.<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 12, 2015 at 6:04 PM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">John,<br>
<br>
It should be fairly straightforward for you to implement this behavior in your application using std::future::wait_for.<br>
<br>
<br>
Jon<span><br>
<br>
On 1/12/15 6:33 PM, John Sully wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
Yes it already runs on a separate thread; however when its known the<br>
result is no longer necessary (for example the user changed the cursor<br>
location - negating the need for autocomplete at the previous location)<br>
the separate thread still runs consuming resources.<br>
<br>
On slower devices like laptops these operations can take a long time.<br>
Even if we are willing to accept the waste of cycles (and battery<br>
life!), the processor has a limited number of cores and responsiveness<br>
will be poor if too many "zombie" jobs are still running.<br>
<br>
I'm willing to add this functionality and submit it upstream if<br>
necessary, but prior to doing so I wanted to reach out to current<br>
developers. It would be unfortunate to invest significant effort only<br>
to find my patch can't be accepted for an avoidable reason.<br>
<br>
<br>
On Mon, Jan 12, 2015 at 4:09 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a><br></span><span>
<mailto:<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>><u></u>> wrote:<br>
<br>
Have you tried running libclang on a separate thread?<br>
<br>
On Sun, Jan 11, 2015 at 7:59 PM, John Sully <<a href="mailto:john@csquare.ca" target="_blank">john@csquare.ca</a><br></span><span>
<mailto:<a href="mailto:john@csquare.ca" target="_blank">john@csquare.ca</a>>> wrote:<br>
<br>
I'm in the process of writing an editor based upon libclang, and<br>
a major issue I'm hitting is the inability to cancel long<br>
running tasks. The primary tasks are parsing and creation of<br>
auto-complete results.<br>
<br>
Is there already functionality to do this that I've missed?<br>
<br>
If not, I would like to implement this as its a requirement to<br>
get good responsiveness out of my editor. Has there been any<br>
prior discussions on how this should be implemented?<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br></span>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a> <mailto:<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><span><br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
<br>
</span></blockquote><span><font color="#888888">
<br>
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br>
</font></span></blockquote></div><br></div>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div></div></div>
</blockquote></div><br></div>