Email list hosting service & mailing list manager

networked application with libuv Amirouche Boubekki (12 Oct 2020 06:52 UTC)
Re: networked application with libuv Lassi Kortela (12 Oct 2020 08:06 UTC)
Re: networked application with libuv Amirouche Boubekki (12 Oct 2020 12:29 UTC)
Re: networked application with libuv Lassi Kortela (15 Oct 2020 18:44 UTC)
Re: networked application with libuv Amirouche Boubekki (17 Oct 2020 09:16 UTC)

Re: networked application with libuv Amirouche Boubekki 12 Oct 2020 12:29 UTC

Le lun. 12 oct. 2020 à 10:06, Lassi Kortela <xxxxxx@lassi.io> a écrit :
>
> > 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 become more complex over time.

Yes. I did not come to this suggestion lightly. The thing is relying
on raw POSIX or Windows API is error prone and does not work all the
time because you need errno.

The word that must be stressed is "portable".

> 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.

The advantage of libuv is that a) it does not expose errno, b) it is
portable across many platforms, runtimes (windows, POSIX, musl, glic),
and scheme implementations.

> > 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.

I am sure you know that sample implementations are useful to drive the
specification of useful libraries forward, and give a baseline that
may work on many schemes. libuv will allow us to build and test
network libraries on many schemes.

> > 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).

I am not sure what I am supposed to do? I suggest I will work on libuv
bindings, that work can benefit many Scheme implementations especially
those that support r6rs-pffi. Gambit in particular, might not benefit
from those bindings directly, higher level libraries will abstract the
uv-specific bits, so it will be useful eventually.

Guile can benefit from libuv bindings even if they have their own
socket-port machinery. Loko is not interested in C bits.

AFAIU, CML based on ports is compatible with libuv when you have custom ports.

Consider the libuv bindings just a chime to bring as much Scheme
implementation onboard the network party.

--
Amirouche ~ https://hyper.dev