What did you (MA) mean by "hangs"?  If read-sequence/usocket-stream  is built upon or named to resemble READ-SEQUENCE, isn't it just fulfilling its contract?  As described in the ANS, R-S never returns normally until it has read and modified the entire sequence (modified by :START/:END) unless end of file occurs.  Perhaps READ-SEQUENCE is not the correct API for what you need for your communication channel, since the contract of R-S is inappropriate upon which to build a variable-record-length protocol.

Several previous comments were obviously constructed on top of this understanding about READ-SEQUENCE, but I didn't see any that made explicit this important point.  During the X3J13 process the committee realized that the ancient Lisp I/O functions, which might have been fine for single-char teletype support, would need bulk functions in the language or else each implementation would have to invent its own (which is eventually how it worked out).  READ- and WRITE-SEQUENCE were added as the place in the language to hang these things, trusting on mythological implementation competition forces to work out the details, but obviously it wasn't well thought out.  As explained at the start of my message, R-S is both over- and under-defined to be the base for efficient communication protocols, modern circa the 1990's.

On Wed, Dec 17, 2025 at 11:06 AM David McClain <dbm@refined-audiometrics.com> wrote:
Ahem… the Async Socket system *does not* require a separate thread per socket. I just run one collection manager thread to handle all of the socket connections established with my systems. All of my systems act as either client or server, depending on who initiates a connection. And they all only need one collection manager, which is developed on demand.

On Dec 17, 2025, at 11:59, David McClain <dbm@refined-audiometrics.com> wrote:

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 <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