> I looked around and there is no other cross-platform bsd-like socket
> except libuv (https://libuv.org/).

Many good programmers love libuv. I suggested to Feeley last year that
Gambit use it, but he'd like to keep Gambit free of external
dependencies, which is probably a good decision. libuv gets a ton of
commits and issues all the time, which is a sign of good health, but
also makes it somewhat of a moving target, and probably means it will
gradually get become more complex over time.

Scheme implementations tend to have their own poll/thread/signal
framework that ties into the memory manager and continuations. Since
libuv involves the same stuff, it may be necessary to integrate those
bindings at a deeper level than most libraries. The bindings probably
have to be tailor-made for each implementation.

> If we have cross platform bindings for that it will allow us to create
> a couple portable implementations for on-going pre-srfi like http, p2p
> and cell-terminal. Possibly others like database drivers?

All of those are useful for sure. But should probably not depend on
libuv specifically.

> Even if it
> is a lot of work to create database drivers starting at the wire
> protocol.

If we have some kind of S-expression based specification language for
the data layout of the network packets, maybe those specifications could
be shared with Common Lisp and Clojure database drivers? That would
reduce the amount of Scheme-only code needed.

> I think I will start a specification for libuv low level but schemey bindings.

Sounds like a good idea but would benefit a lot from input from Scheme
implementors. The last threads-in-R7RS-large discussion didn't come to a
conclusion. Marc Feeley likes SRFI 18 threads; John Cowan suggested a
SRFI-18-like Futures abstraction; Guile and Loko use Fibers (aka
Concurrent ML).