[Openmcl-devel] type specifier '(simple-vector n) in defmethod

[David McClain]

I honestly don’t know the underlying mechanism used by LW. But there is nothing preventing you setting up a multitude of asynchronous collections. I only utilized one for my system. Each collection handles as many connections as you allow.

I’m not a high-performance network expert, and I can’t say how well such a collection of async collections would scale in a large system. But I have a hard time imagining that the use of Green Threads and artifices involved in callback management (Callback-Hell) would perform better than this much simplified approach. Perhaps I’m too ignorant of the problem domain…



> On Jan 6, 2024, at 11:02, Nicolas Martyanoff <nicolas at n16f.net> wrote:
> 
> David McClain <dbm at refined-audiometrics.com> writes:
> 
>> I have been using Async Socket I/O in Lispworks, qute successfully for several
>> years now. Even with multiple connections, it requires only a single machine
>> thread to run a dedicated socket handler. LW must be using a Select() down deep
>> inside, but I haven’t looked. There is no problem with idle socket connections.
>> 
>> The dedicated handler thread hands off incoming packet fragments to one or more
>> of my own waiting user code fragments which run in one of my pool threads. The
>> entire thing runs in my laboratory with 4 or more networked machines, where I
>> have in each machine just one socket handler thread, and a pool of 8 worker
>> threads for myself. None of my code sits waiting for incoming socket data, but
>> responds whenever fresh data arrive.
> 
> Now expand your system to thousands of concurrent connections, and see
> what happens when processing each requests means running other IO
> requests (e.g. calling external systems, or even simply disk
> operations). Processing is now split on a multitude of IO event
> callbacks (this is the definition of callback hell), making code so much
> more difficult to follow. And of course each callback now has the
> potential to delay other IO callbacks since they all run on the same
> thread. Very fun when you realize that your apparently inoffensive read
> on a file actually reads a NFS-mounted volume and the 30 second timeout
> will delay all other IO events.
> 
> None of this really matters for tiny applications running in controlled
> environments. But on large scale production systems, they do.
> 
> I would also hope that LW uses at least poll, and hopefully
> epoll/kqueue).
> 
> -- 
> Nicolas Martyanoff
> https://n16f.net
> nicolas at n16f.net