Hi Steve I understand that, and I know about the idiosyncrasies of the bulk operations under different implementations.
I am asking what would be the best way to, say, implement a READ-SEQ-NO-HANG (for want of a better name) using USOCKET provided primitives; yes I am working with sockets. Reading a byte at a time and listening would work? Any better ideas? I am fooling around as we speak. Any suggestion will be welcome; the only constraint: using USOCKET. Cheers MA On Wed, Dec 17, 2025 at 9:47 PM Steve Haflich <[email protected]> wrote: > 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 < > [email protected]> 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 <[email protected]> >> 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 <[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]>: >> >> 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 >> >> >> >> -- Marco Antoniotti, Professor, Director tel. +39 - 02 64 48 79 01 DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY REGAINS: https://regains.disco.unimib.it/
