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 <manfred.bergmann@me.com> 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 <dbm@refined-audiometrics.com>:
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