<div dir="ltr">I generally like the API being proposed, especially structurally.<div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 15, 2014 at 10:50 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Given the use case (user mode
      scheduling), I'm not going to oppose this proposal.  I would like
      to see a couple of things clarified documentation wise:<br>
      - When is this interface valid?  (i.e. the single thread case)<br>
      - If a context does have multiple threads, is this called once per
      thread?  Or once per thread group after internal coordination? 
      (you can write this out of scope if desired)<br>
      - If we later introduce multiple threads, and this mechanism
      doesn't support it, what will happen?  Will the function just not
      be called?  <br>
      - You hint at this already, but clarifying the state of the
      current context at a suspend point would be helpful.<br></div></div></blockquote><div><br></div><div>+1, i think clarifying a lot of this context and getting it baked into the docs is key.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div>
      <br>
      Here's a possible draft that includes the above:<br>
      <font face="Menlo">The may-suspend callback function may be called
        by LLVM to transfer control back to the client that invoked the
        LLVM compilation. This can be used to yield control of the
        thread, or perform periodic work needed by the client.  There is
        no guaranteed frequency at which callbacks must occur; in fact,
        the client is not guaranteed to ever receive this callback. It
        is at the sole discretion of LLVM to do so and only if it
        can guarantee that suspending the thread won't block any forward
        progress in other LLVM contexts.  </font><br>
      <br>
      <font face="Menlo">At a suspend point, the state of the current
        LLVM context is intentionally undefined.  No assumptions about
        it can or should be made.  In particular, call backs into the
        context are not supported until the suspend function returns
        control to LLVM.  Other LLVM contexts are unaffected.  <br>
        <br>
      </font>Currently, LLVM assumes one thread per LLVM context.  If,
      or when, we introduce multiple threads, this interface will not be
      available for contexts which opt-in to the thread pool model.  We
      may extend this interface at a later time to support thread pools,
      but for the moment, that use case is explicitly unsupported.  <br>
      <br>
      <br>
      p.s. Bikeshed wise, might "yield" be a better term than "suspend"
      here?<br></div></div></blockquote><div><br></div><div>I have to say I like yield better. I'm not set on it.</div><div><br></div><div>I don't think we need the "may" prefix either way. Wether or not (or for how long) a suspension happened is (necessarily) not something that LLVM should be observing. I think the caller should be assuming that it *will* happen, and so the API needn't be cagey about it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      <br>
      Philip<div><div class="h5"><br>
      <br>
      On 05/13/2014 11:49 AM, Juergen Ributzka wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="h5">
      
      <div>Sounds good. Lets get started by nailing down the C API and
        semantics for this first.</div>
      <div><br>
      </div>
      <div>I mirrored the C API for the LLVM context diagnostic handler
        and used Andy’s suggested name for the callback.</div>
      <div>The opaque handle was suggested by Duncan and can provide
        optional user specified information that is</div>
      <div>provided back during the callback (i.e. barrier, etc).</div>
      <div><br>
      </div>
      <div>Cheers,</div>
      <div>Juergen </div>
      <div><br>
      </div>
      <div>
        <div><font face="Menlo">Core.h:</font></div>
        <font face="Menlo">typedef void
          (*LLVMMaySuspendCallback)(LLVMContextRef, void *);</font>
        <div><font face="Menlo"><br>
          </font></div>
        <div><font face="Menlo">/**</font></div>
        <div><font face="Menlo"> * Set the may-suspend callback function
            for this context.<br>
             *<br>
             * @see LLVMContext::setMaySuspendCallback()<br>
             */<br>
            void LLVMContextSetMaySuspendCallback(LLVMContextRef C,<br>
                                                  LLVMMaySuspendCallback
            Callback,<br>
                                                  void *OpaqueHandle);</font></div>
        <div><font face="Menlo"><br>
          </font></div>
        <div><font face="Menlo">LLVMContext.h:</font></div>
        <div><font face="Menlo">/// \brief Registers a may-suspend
            callback with the context.<br>
            ///<br>
            /// The may-suspend callback function may be called by LLVM
            to transfer<br>
            /// control back to the client that invoked the LLVM
            compilation. The client<br>
            /// is not garantueed to ever receive this callback. It is
            at the sole<br>
            /// discretion of LLVM to do so and only if it
            can guarantee that suspending<br>
            /// the thread won't block any forward progress in other
            LLVM contexts.<br>
            void setMaySuspendCallback(MaySuspendCallbackTy Callback,
            void *OpaqueHandle);<br>
            <br>
            /// \brief Calls the may-suspend callback (if applicable).<br>
            ///<br>
            /// This transfers control back to the client, which may
            suspend the current<br>
            /// thread. Only call this method when LLVM doesn't hold any
            global mutex or<br>
            /// cannot block the execution in another LLVM context.<br>
            void callMaySuspendCallback();</font></div>
      </div>
      <div>
        <div><br>
          <div>
            <div>On May 12, 2014, at 5:26 PM, Nick Lewycky <<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>>
              wrote:</div>
            <br>
            <blockquote type="cite">
              <blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

                <div style="word-wrap:break-word">Would you (or
                  anyone) oppose a simple maySuspendContext() callback
                  API? It would mean nothing more than the thread(s) for
                  a given LLVM context can be suspended independent from
                  other contexts.</div>
              </blockquote>
              <div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br>
              </div>
              <div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
I
                think this is the right approach. So a given thread hits
                a safe point, it optionally calls a "suspend check" or
                "i an safe to suspend right now" callback if set. It
                doesn't stop other threads, it doesn't continue until
                the function returns.</div>
              <div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br>
              </div>
              <div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
If
                you want to stop all threads then the user callback may
                contain a barrier and count down how many threads have
                stopped until it sees all of them.</div>
              <div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br>
              </div>
              <div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Nick</div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><div class=""><pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
    </div></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>