Make radicle-node asnyc?
From what I see is the code in radicle-node not async.
Would such a (rather big and definitively non-trivial) change be desired?
We could gradually move bits to be async and periodically merge small changes
to make stuff more and more async over time, eventually reaching a point
where the node is completely async rather than “worker-thread’y” :-)
I would love to investigate what is needed to do this, but I don’t want to start sending big chunks of code changes to the radicle-node subtree without having at least some discussion whether such changes are desired or not.
My first patch in that direction would actually be replacing log with
tracing, which I think is a prerequisite for a sensible and orderly move to
async.
Please discuss!
Thanks for opening this topic up! The fact that
radicle-nodeis notasyncis not documented so it’s a great question to ask :)Historically, the
asyncecosystem was more of a PITA when we originall developing the previous iteration of the Radicle protocol,radicle-link. It was a conscious decision to go forward and specifically not useayncinheartwood. And this has served us pretty well to get where we are today.That being said, the
asyncecosystem seems to be improving over time and it might be worth revisiting these things again. At the moment, I’m working a sans I/O draft of the protocol code, which can be found at:I think this will open up the door for experimenting with an
asyncimplementation ofradicle-node– we have been thinking about experimenting with something likeirohorlibp2pas well for the networking layer.So, it might be premature to start chipping away at this task, I’d prefer get the sans I/O work together first and see where to go from there. If you have feedback or input on that front, then please feel free to chip in on the Zulip topic https://radicle.zulipchat.com/#narrow/channel/383670-patches/topic/radicle-protocol.3A.20Sans-IO-ification/with/533453314
<3
I love this effort! I am working (in my day job) on a […] sans-io library there which is absolutely awesome to write tests for just because of it being sans-io. Having sans-io is not a hard requirement for trying to get the node being async, but it most likely will make things really nice!
I played with both and don’t like either, but that’s possibly because I didn’t get basic things to work for me … YMMV of course!
Yes please!
Ya, I’ve been making more of an effort to think about where I/O is actually needed and keeping a pure core – and testing that pure core is so much nicer!
And ya, I don’t think the effort is necessary to get to async, however, the set of libraries that drive the network services in
radicle-nodeare handcrafted to avoid using an async runtime. You may have seen Lorenz modifying them to get to work on Windows. So I think where I’d like to get to is having those under our control, having the sans I/O code, and then exploring the async runtime.Interesting, I’ve seen good praise about
iroh, and they seem to have simplified things when it comes to comparing/contrasting tolibp2p. Happy to hear about other alternatives. Hopefully sans I/O makes it easy to toy with different alternatives!Last time I checked they did not even yet have proper error types in their API any always returned anyhow::Error - not a library I would like to rely on if you couldn’t even do proper error handling with their API. I filed an issue (years ago I think) of course, but I don’t know what the current state of affairs is.
If they sorted it out, it might be worth another look I guess.