4 comments

[ 2.9 ms ] story [ 15.5 ms ] thread
This is my attempted at something that makes using Common Lisp with Datastar easier. To test the SDK I made this demo that shows the simulation of the Cassini-Huygens mission using the NASA SPICE toolkit and JPL Horizons API: https://dataspice.interlaye.red/

The Datastar API itself is very simple, 3 functions or so, I ended up wasting a lot more time on stuff like leeping the SSE stream open, compression support (zstd only atm), and trying to use CLOS in a way that would fit both Hunchentoot and Clack (not always easy).

> Each SSE connection blocks one worker for its entire duration.

Have you tried wookie? Such extreme case of blocking the event loop... negates any benefit of async processing.

An update: I've spent some time taking a much deeper look, and while I can't guarantee it's perfect, I added a different approach for Clack+Woo, documented here: https://github.com/fsmunoz/datastar-cl/blob/main/SSE-AND-WOO...

In short: I've replace the Common Lisp loop (that works for Hunchentoot since it opens threads, but doesn't for Woo since it blocks) with a deeper integration into the event loop:

> And that was the main change: looking at the innards of it, there are some features available, like woo.ev:evloop. This was not enough, and access to the libev timer was also needed. After some work with lev and CFFI, the SDK now implements a Node.js-style approach using libev timers via woo.ev:evloop and the lev CFFI bindings (check woo-async.lisp).

This is likely (almost surely) not perfect or even ideal, but it does seem to work, and I've been testing the demo app with 1 worker and multiple clients.

Thanks for sharing. I’m curious why the example SPICE application uses Fortran to parse the SPICE data?