Thank you Reid, that makes alot of sense now.  Is there an API to the JIT functionality?  If so, <div>could you point out where in the code base it lives, and if there are examples of clients (how to</div><div>use it?)</div>
<div><br></div><div>Thanks!</div><div>Jason<br><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 1:58 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:reid.kleckner@gmail.com">reid.kleckner@gmail.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="im">On Wed, Mar 16, 2011 at 2:52 PM, Jason E. Aten <<a href="mailto:j.e.aten@gmail.com">j.e.aten@gmail.com</a>> wrote:<br>

> Jim, thank you--that makes alot of sense. I hadn't thought through the<br>
> signal implications.  And re-reading Reid's post, he does make it clear that<br>
> the JIT-code injection is somehow a part of an interprocess communication.<br>
> The question then becomes, does the DNB.h protocol support the JIT-code<br>
> injection, or if not, could that be a part of it?<br>
<br>
</div>Yup, it works similar to the way debuggers find out about dynamically<br>
loaded libraries.  There's a particular loader stub that gets called<br>
after every library load or unload.  Debuggers put a breakpoint on it<br>
to stop the inferior process and re-read the list of loaded libraries<br>
with remote memory examination routines, so there's your (hacky) IPC.<br>
<font color="#888888"><br>
Reid<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Jason E. Aten, Ph.D.<br><br><br>
</div>