<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Thanks for the feedback guys.<br>
      <br>
      Studying the code, I had figured going with a straight int would
      in practice be most efficient and not run into multi-threaded
      problems, even if initially appearing a bit risky.  I will rework
      it to use a std::condition_variable.  That will be more robust and
      readable.<br>
      <br>
      Shawn.<br>
      <br>
      On 7/29/2014 10:53 AM, Zachary Turner wrote:<br>
    </div>
    <blockquote
cite="mid:CAAErz9jD07cDjWmmOofQKJXHKHjECyN3Q7T=N2j9=ndx8ZsVPA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Even better would be an std::condition_variable</div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Mon, Jul 28, 2014 at 10:30 PM,
          Matthew Gardiner <span dir="ltr"><<a
              moz-do-not-send="true" href="mailto:mg11@csr.com"
              target="_blank">mg11@csr.com</a>></span> wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Shawn,<br>
            <br>
            I use 64-bit linux and I see this issue a lot. It usually
            manifests itself as the prompt just not being printed (or
            perhaps it just gets overwritten) - regardless - I invoke a
            command, and I don't see an (lldb) prompt when I should. So
            I'm well pleased that you are looking at this!<br>
            <br>
            Would it not be more robust to use a semaphore than usleep
            to synchronise the problematic threads?<br>
            <br>
            Although I've not looked too deeply into this particular
            issue, whenever I've seen similar races, I found that it's
            almost impossible to pick the right value when using a sleep
            command. A semaphore, though, should always ensure the
            waiting thread will wake precisely.<br>
            <br>
            I'd be happy to help to test such a fix.<br>
            <br>
            Matt<br>
            <br>
            <br>
            Shawn Best wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>
                <div class="h5">
                  Hi,<br>
                  <br>
                  I have attached a patch which addresses 3 related race
                  conditions that cause the command line (lldb) prompt
                  to get displayed inappropriately and make it appear it
                  is not working correctly.  This issue can be seen on
                  linux and FreeBSD.  I can also artificailly induce the
                  problem on OSX.<br>
                  <br>
                  The issue happens when the command handler (in the
                  main thread) issues a command such as run, step or
                  continue.  After the command finishes initiating its
                  action, it returns up the call stack and goes back
                  into the main command loop waiting for user input.
                   Simultaneously, as the inferior process starts up,
                  the MonitorChildProcess thread picks up the change and
                  posts to the PrivateEvent thread.  HandePrivateEvent()
                  then calls PushProcessIOHandler() which will disable
                  the command IO handler and give the inferior control
                  of the TTY.  To observe this on OSX, put a<br>
                  <br>
                  usleep(100);<br>
                  <br>
                  immediately prior the PushProcessIOHandler() in
                  HandlePrivateEvent.<br>
                  <br>
                  <br>
                  My proposed solution is that after a 'run', 'step', or
                  'continue' command, insert a synchronization point and
                  wait until HandlePrivateEvent knows the inferior
                  process is running and has pushed the IO handler.  One
                  context switch (<100us) is usually all the time it
                  takes on my machine.  As an additional safety, I have
                  a timeout (currently 1ms) so it will never hang the
                  main thread.<br>
                  <br>
                  Any thoughts, or suggestions would be appreciated.<br>
                  <br>
                  Regards,<br>
                  Shawn.<br>
                  <br>
                  <br>
                </div>
              </div>
              To report this email as spam click here <<a
                moz-do-not-send="true"
                href="https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ=="
                target="_blank">https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==</a>>.<br>
              <br>
              <br>
              <br>
              _______________________________________________<br>
              lldb-commits mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:lldb-commits@cs.uiuc.edu" target="_blank">lldb-commits@cs.uiuc.edu</a><br>
              <a moz-do-not-send="true"
                href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits"
                target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits</a><br>
            </blockquote>
            <br>
            <br>
            <br>
            Member of the CSR plc group of companies. CSR plc registered
            in England and Wales, registered number 4187346, registered
            office Churchill House, Cambridge Business Park, Cowley
            Road, Cambridge, CB4 0WZ, United Kingdom<br>
            More information can be found at <a moz-do-not-send="true"
              href="http://www.csr.com" target="_blank">www.csr.com</a>.
            Keep up to date with CSR on our technical blog, <a
              moz-do-not-send="true" href="http://www.csr.com/blog"
              target="_blank">www.csr.com/blog</a>, CSR people blog, <a
              moz-do-not-send="true" href="http://www.csr.com/people"
              target="_blank">www.csr.com/people</a>, YouTube, <a
              moz-do-not-send="true"
              href="http://www.youtube.com/user/CSRplc" target="_blank">www.youtube.com/user/CSRplc</a>,
            Facebook, <a moz-do-not-send="true"
              href="http://www.facebook.com/pages/CSR/191038434253534"
              target="_blank">www.facebook.com/pages/CSR/191038434253534</a>,
            or follow us on Twitter at <a moz-do-not-send="true"
              href="http://www.twitter.com/CSR_plc" target="_blank">www.twitter.com/CSR_plc</a>.<br>
            New for 2014, you can now access the wide range of products
            powered by aptX at <a moz-do-not-send="true"
              href="http://www.aptx.com" target="_blank">www.aptx.com</a>.<br>
            _______________________________________________<br>
            lldb-commits mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:lldb-commits@cs.uiuc.edu" target="_blank">lldb-commits@cs.uiuc.edu</a><br>
            <a moz-do-not-send="true"
              href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits"
              target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>