portal VS Common-Lisp-Actors

I have an external server, and I can ask it for data with a request over http. However the reply comes in on a different listening websocket (using Portal: https://github.com/charJe/portal/ ). The reply will contain the same ID I sent in my request, so I'll be able to identify it, however, there'll be plenty other incoming messages interleaving.

There are very, very competent concurrency libraries already. I pointed you to them already. They serve as primitives to roll your own solutions -- You can get most of the functionality of Erlang actors (and virtually all of the important parts regarding concurrency) with threading (green or OS), CSP channels, and writing a few macros. Go look at a lot of the actor libraries you mentioned that are "long dead" and you'll notice they do A LOT with just a few hundred lines of code. This one gets basic functionality with just straight threading primitives in 131 lines.

As an alternative I was considering actors, f.ex. https://github.com/naveensundarg/Common-Lisp-Actors ,which seems simple enough. But the actor paradigm seems to require that all my code lives in actors. While I could make an actor that receives a message from the websocket listener when a message is incoming, it's a bit of a cumbersome setup compared to the linear looking code above. Since the message coming in will be decoupled from the request asking for the data, so it feels awkward. But maybe I'm thinking about it all wrong.