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: <a href="https://github.com/fsmunoz/datastar-cl/blob/main/SSE-AND-WOO.org" rel="nofollow">https://github.com/fsmunoz/datastar-cl/blob/main/SSE-AND-WOO...</a><p>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:<p>> And that was the main change: looking at the innards of it, there are some features available, like woo.ev:<i>evloop</i>. 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:<i>evloop</i> and the lev CFFI bindings (check woo-async.lisp).<p>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.
I haven't tried Wookie, since adding Clack+Woo was already a substantial change. Reading <a href="https://fukamachi.hashnode.dev/woo-a-high-performance-common-lisp-web-server" rel="nofollow">https://fukamachi.hashnode.dev/woo-a-high-performance-common...</a> , where it compares with Wookie, I'm not sure if it would make a difference: it might be wrong, but "it says:<p>> Of course, this architecture also has its drawbacks as it works in a single thread, which means only one process can be executed at a time. When a response is being sent to one client, it is not possible to read another client's request.<p>... which for SSE seems to be similar to what the issue is with Woo. I wrote a bit more on it in <a href="https://github.com/fsmunoz/datastar-cl/blob/main/SSE-WOO-LIMITATIONS.org" rel="nofollow">https://github.com/fsmunoz/datastar-cl/blob/main/SSE-WOO-LIM...</a> , and it can be more of a "me" problem than anything else, but to keep a SSE stream open, it doesn't play well with async models. That's why I added a with-sse-response macro that, unlike with-sse-connection, sends events without keeping the connection open.