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 Lassi Kortela 12 Oct 2020 08:05 UTC
> 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).