<div dir="ltr"><div dir="ltr">Hi Andres,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I was wondering about it because the function comments didn't mention it<br>(or at least I didn't see it), and not "implicitly" prevent via type<br>system. I don't really have a use case.</blockquote></div><div><br></div><div>I tried to think of a nice way to do this with the type system but everything I tried came out awkward.</div><div><br></div><div>One use case I <i>can</i> think of for cross-dylib tracking is the current system for CompileOnDemandLayer: It creates a ".impl" JITDylib for each JITDylib you add code to, installs the code in the ".impl" JITDylib and builds stubs in the original JITDylib, treating it as a facade. I haven't implemented removal properly for this yet, but my plan was to create new ResourceTrackers as needed and treat them as resources themselves in CompileOnDemandLayer: If you add a module with tracker T then CompileOnDemandLayer would create a tracker T' and record the association key(T) -> T'. Then on removal of T we would extract and trigger removal of T'. If ResourceTrackers worked across JITDylib boundaries we could avoid this, but it's not particularly complicated anyway.</div><div><br></div><div>I'm going to leave the current solution in place for now, but if anyone does come up with a compelling use-case for cross-dylib tracking please let me know. :)</div><div><br></div><div>-- Lang.</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 16, 2020 at 3:13 PM Andres Freund <<a href="mailto:andres@anarazel.de">andres@anarazel.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 2020-09-16 14:53:44 -0700, Lang Hames wrote:<br>
> > I assume it is not legal to use the same resource tracker with two<br>
> > different JITDylib's?<br>
> <br>
> <br>
> That's correct -- ResourceTrackers are bound to the JITDylib they're<br>
> created from. They should assert if you use them with the wrong JITDylib,<br>
> though I'm not sure how good the coverage on those asserts are yet.<br>
> <br>
> I think this system could be generalized to enable cross-dylib tracking at<br>
> the cost of a few dozen extra bytes per tracker. Do you have a use-case for<br>
> this?<br>
<br>
I was wondering about it because the function comments didn't mention it<br>
(or at least I didn't see it), and not "implicitly" prevent via type<br>
system. I don't really have a use case.<br>
<br>
Greetings,<br>
<br>
Andres Freund<br>
</blockquote></div>