[ANN] nanoev 0.1

Community
1

Hello,

I’m happy to announce the first release of nanoev, yet another event loop abstraction. My goal with it is to have a narrow-waist interface between event loops (for now, select and poll) and various abstractions built directly on top (for now using picos), without tying the event loop abstraction itself to a particular scheduler. The core interface for the event loop is basically:

type t

val wakeup_from_outside : t -> unit

val step : t -> unit
(** Run one step of the event loop until something happens *)

val close : t -> Unix.file_descr -> unit
(** Close the file descriptor and clean it up *)

val max_fds : t -> int
(** Maximum number of file descriptors that can be observed at once. *)

val on_readable :
  t -> Unix.file_descr -> 'a -> 'b -> (closed:bool -> 'a -> 'b -> unit) -> unit

val on_writable :
  t -> Unix.file_descr -> 'a -> 'b -> (closed:bool -> 'a -> 'b -> unit) -> unit

val run_after_s : t -> float -> 'a -> 'b -> ('a -> 'b -> unit) -> unit

and nothing else. I’ve also started experimenting with using it to drive tiny_httpd.

docs: https://c-cube.github.io/nanoev/
release link: https://github.com/c-cube/nanoev/releases/tag/v0.1

9 Likes
2

Two quick points of feedback:

  • I don’t understand from reading your post which implementations of this interface you provide in the module. (You mention “various abstractions built directly on top (for now using picos)”, but this does not suggest that a nanoev interface can be built on top of picos, maybe rather the converse or something else.) By looking at the code I see a POSIX implementation.

  • I followed the link you give to the docs, and I end up on a page that does not say what Nanoev is. I even wasn’t able to find, by clicking on a few links from there, a page that says what Nanoev is. (My best guess was nanoev > Nanoev, but no luck.) I find this a bit disappointing as a documentation webpage.

3

Ha! That’s fair, I think. I’ll improve the docs.

The idea is that a Nanoev.t is an encapsulated event loop. There are two implementations, one with select, one with poll (which can handle more than 1024 FDs, woo). Then on top of that, there’s a picos interface that provides things like read and write that relies on nanoev to wakeup the fiber when a FD is ready. But you could also use nanoev from other scheduler abstractions, it’s not tied to picos.