Beyond that there are about eight million LRU caching libraries—which are not what I wanted—and a handful of things that could have worked with enough investment but that didn't integrate cleanly into #eio (it being Very New™ in this world).

So since this is a learning project and I have no deadlines, it made sense to do some from-the-ground-up work.

#OCaml

Why go through all of this trouble rather than just using the #JaneStreet `resource_cache`?

Well, a big part of it is that I wanted to build an actor system with #eio as I was learning #OCaml and that I think the actors will be useful elsewhere in the #JsonLD project :p

Another piece of it is that the docs on resource_cache ( https://ocaml.org/p/resource_cache/latest/doc/Resource_cache/index.html ) are not entirely clear and it roots into #async, which isn't a problem per se but I've been trying to stay as close to eio alone as possible.

Hah! Okay, I was doing several things incorrectly to create the deadlocks in my #OCaml project.

First thing was, as I mentioned yesterday, creating essentially an infinite series of latches that would never clear until the infinite loop ended (whoops).

The second was unsafely mixing Channels from #Domainslib and #Eio. These, it turns out, don't play nicely together.

The final issue was a little more subtle and not a deadlock _per se_.

Playing around with the new multicore support in #OCaml along with #eio and I gotta say, this behaves more-or-less exactly like what I want a multicore library to behave like.

The documentation isn't all there yet, but it's very nice.