https://pantsbuild.org/ logo
#development
Title
# development
a

average-vr-56795

05/01/2019, 5:06 PM
Heads up, I’m making
Externs
actually injected into each ffi function into
Native
, rather than having them being global statics 🙂
w

witty-crayon-22786

05/01/2019, 5:18 PM
not quite sure what this means
a

average-vr-56795

05/01/2019, 5:19 PM
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

witty-crayon-22786

05/01/2019, 5:21 PM
oh. interesting.
that feels like it would make the logging initialization harder? or would the logging initialization still happen statically?
a

average-vr-56795

05/01/2019, 5:22 PM
Logging initialisation still happens statically, but where it needs externs it’ll force them to be set during the initialisation
w

witty-crayon-22786

05/01/2019, 5:23 PM
what's the benefit then...?
a

average-vr-56795

05/01/2019, 5:23 PM
We lose a few
From
implementations, but otherwise it’s just moving a little code around 🙂
(And dropping a lock)
w

witty-crayon-22786

05/01/2019, 5:23 PM
oh, so: it's possible to replace that lock, btw
a

average-vr-56795

05/01/2019, 5:24 PM
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

witty-crayon-22786

05/01/2019, 5:24 PM
i have a branch that replaces it with arc_swap... there just didn't seem to be any performance benefit
a

average-vr-56795

05/01/2019, 5:24 PM
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

witty-crayon-22786

05/01/2019, 5:24 PM
but if the logging initialization is still static, it's not clear what the benefit is
a

average-vr-56795

05/01/2019, 5:25 PM
The benefit is a code-enforced dependency between initialisation and consumption, rather than an implicit one
w

witty-crayon-22786

05/01/2019, 5:25 PM
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

average-vr-56795

05/01/2019, 5:27 PM
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

witty-crayon-22786

05/01/2019, 5:27 PM
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

average-vr-56795

05/01/2019, 5:31 PM
Hmm… Interesting thoughts… I’ll have a play 🙂
w

witty-crayon-22786

05/01/2019, 5:34 PM
@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 =/