Found another snag re: dynamic linking Rust code — N copies of `tokio` are present, so that's N distinct thread-locals storing the "current tokio context"
...and the binary is calling the library from an executor, but the library doesn't think so.
Found another snag re: dynamic linking Rust code — N copies of `tokio` are present, so that's N distinct thread-locals storing the "current tokio context"
...and the binary is calling the library from an executor, but the library doesn't think so.
@cjk @fasterthanlime haha, I understand this is a thing Not To Be Done, but I'm super curious about how you did it & what happened. did you write anything up or post code anywhere, maybe?
@fasterthanlime I once wrote a task runner library with different queues and priorities and all the bells and whistles.
I spawned a tokio runtime for every queue, with a configurable amount of workers.
Oh boy, did I regret that. 🫣
Well, it’s nothing nested tokio runtimes cannot fix 🤡
@cjk @fasterthanlime Gotcha! That makes sense, most of my work is just the same. If you do wind up writing anything up one day, I'd love to read it though!
@ironchamber @fasterthanlime no, sorry. This was an internal project, and I couldn’t fix the problems, so I just threw it away and wrote a much simpler approach with Redis as a message broker and distinct worker processes. I did not write about it.
But maybe I should 🤔 the code is still available in the git history.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.