<@U06A03HV1> would it make sense to rewrite the st...
# development
h
@witty-crayon-22786 would it make sense to rewrite the streaming workunit handler to Rust so we spawn the thread with tokio, rather than via Python's
thread
library?
w
maybe? at its core it would still need to be something like a context manager wrapped around the run (or a try:finally)… but it couldn’t literally be a context manager i don’t think
i think that we’re likely to be spawning fewer and fewer threads in python over time, and that could be an argument for doing it.
but not clear.
h
I'm a little confused how the logging is getting set up correctly to write to
pants.log
atm? Is Tokio somehow tracking what threads Python is spawning?
w
no, it isn’t. but the default destination for a thread with no destination set is Logging
and this is a thread with no destination set
👍 1
h
i think that we’re likely to be spawning fewer and fewer threads in python over time
It looks like nailgun/pantsd are the only other places we do this?
w
yea. and i noticed the other day that ~most of nailgun is dead code.
👍 1
it’s basically just the pantsd services.
@hundreds-father-404: but fwiw, i’m not sure a “spawn a thread” API or “run a SWH” API are thinner than a get_destination/set_destination API
up to you.
because you still need the optional joining, etc
h
I don't mean a "spawn a thread" API, I was envisioning that most of that logic would be in Rust itself But honestly I'm a little unclear how to proceed in general
w
@hundreds-father-404: in that case, just do the set/get destination thing.
👍 1
(and if you have questions, ping me)
h
Thanks. I do, but trying to knock out this other thing first to have a win hah
👍 1