https://pantsbuild.org/ logo
Join Slack
Powered by
Heads up, I’m making `Externs` actually injected i...
# development
a
Heads up, I’m making 
Externs
actually injected into each ffi function into 
Native
, rather than having them being global statics 🙂
w
not quite sure what this means
a
Rather than us calling 
set_externs
once and then everything grabbing it from a global static 
Mutex<Externs>
, I’m going to have things like 
scheduler.product_request
pass around a handle to an immutable 
Externs
object
So that things that need externs are guaranteed to have them injected
w
oh. interesting.
that feels like it would make the logging initialization harder? or would the logging initialization still happen statically?
a
Logging initialisation still happens statically, but where it needs externs it’ll force them to be set during the initialisation
w
what's the benefit then...?
a
We lose a few 
From
implementations, but otherwise it’s just moving a little code around 🙂
(And dropping a lock)
w
oh, so: it's possible to replace that lock, btw
a
The thing that made me want to do this is that when I did the static logging initialisation, I got an off-main-thread panic because the externs hadn’t been initialised.
w
i have a branch that replaces it with arc_swap... there just didn't seem to be any performance benefit
a
Rather than forcing an unused 
self.context
call before the logging initialisation, I figured I’d solve the root cause of the problem by just passing the required context into the function
w
but if the logging initialization is still static, it's not clear what the benefit is
a
The benefit is a code-enforced dependency between initialisation and consumption, rather than an implicit one
w
i guess that the panic isn't possible anymore, but it's still definitely possible not to have statically initialized early enough
...such that you miss logging
it's not super clear that it's a win though. guaranteeing initialization has happened very early seems... important
a
My goal is to make it so that if you call a function which needed the initialisation to already have happened, you find yourself needing to construct the object that does the initialisation so that you can pass it as a parameter to that function.
w
if these weren't literally static functions, the argument would be stronger i think
passing them everywhere sortof obscures that fact
for example, if there was a way to have them be lazily loaded from the rust side, we'd definitely want to do that
... a well known entrypoint on the python side that the rust code could call to initialize them...?
a
Hmm… Interesting thoughts… I’ll have a play 🙂
w
@average-vr-56795: if we were directly linked against python (which at this point would have almost no cost, since we're building once per python interpreter), the externs would be lookups for well-known python symbols
unfortunately, PyO3 requires nightly at the moment =/
Open in Slack
PreviousNext
Powered by