Hacker News new | ask | show | jobs
by MattHood0 1342 days ago
Very cool! I like that the author chose socket-based communication over a C FFI, which I assume might lead to better reliability and a cleaner API on the Lisp side. Are there any disadvantages to sockets vs. FFI? Any additional, perceivable latency?
2 comments
spelmachine 1342 days ago
Hi! I'm the author of Wayflan.

I chose to use FFI for sockets so that I can have access to sendmsg(), which lets me send file descriptors on the same message as mundane I/O. It also comes with a small bonus that I get to use scatter/gather arrays to move I/O around, which means less byte-shifting when having to deal with incomplete messages.

I'm not sure I understand your question between sockets vs. FFI. Anything not built on FFI would have to come from an impl extension (or a compatibility layer, which would still have to be built on-top of the former two). AFAIK not even SBCL's sb-posix send fd's across -- they still list sendmsg() in a TODO.

As for latency, I haven't benchmarked performance yet. I want to write a collection of desktop apps driving Wayflan to make sure the API is solid, before I do any benchmarking. However, I know one possible advantage over C's libwayland. Libwayland stores a message signature as a string, which runs through an "interpreter" to learn how to decode a message. Wayflan expands a message signature into a function directly via a couple layers of macros.

link
sgtnoodle 1342 days ago
If the client and server are doing blocking recvs or spinning CPU cores, then it's probably 5-10uS of latency. If they're doing something fancier like select/poll/epoll, it could be more like 50-100uS of latency. A direct function call would presumably be significantly less than 1uS, although it really depends on what the function is doing.
link
Jtsummers 1342 days ago
https://wayland.freedesktop.org/docs/html/ch04.html#sect-Pro...

Wayland clients already communicate with the compositor via sockets. This is no different, the main thing will be being able to produce a Lisp-centric API rather than directly using the existing libwayland-client or another library's API.

link