Yes, ok. I really don’t know the mechanism used by LW underneath the Async Sockets.
Perhaps a blocking read + periodic timeout? It isn’t important for my purposes to know how it happens. But I can tell you that it is very effective, from the perspective of my application code. I do know that it fires up a separate thread to run a collection manager. Probably does not need one thread per socket. I suspect there is a Unix Select() involved when more than one socket is assigned to an asynchronous collection manager. When I first started using it, the interface seemed a bit arcane. But after a short time, it became second nature. It makes perfect sense to have an asynchronous socket system in my code. I don’t ask for data from any source. But I respond asynchronously to messages posed by any data source. > On Dec 17, 2025, at 11:39, Manfred Bergmann <[email protected]> wrote: > > I meant in case we have a blocking situation. > Of course a socket read timeout will eventually release the blocking. > > I didn’t look closely at the async implementation. But I’d guess it’s just > async over a socket that block on reading? > > >> Am 17.12.2025 um 17:57 schrieb David McClain <[email protected] >> <mailto:[email protected]>>: >> >>> DDoS in a way that when the receiver blocks it blocks a thread and either >>> you can’t receive anything anymore on other connections. >>> Or it will consume a ton of other threads which may all block. >>> >> >> ??? I don’t understand what you are trying to say here. >> >> I cannot imagine a situation in which my Async Sockets get blocked in that >> manner. And the self-sync protocol will not get tangled up on any inputs. >> Errors simply cause the self sync to scan forward, dropping all, until it >> recognizes another start-sync sequence. >> >> ——————— >> FWIW, you care welcome to peruse my implementation of Async Sockets and >> self-sync protocol here: >> >> https://github.com/dbmcclain/Lisp-Actors/tree/main/xTActors/secure-channel
