vans163

> For every receive size 0, yes. :-( What about `active, once`? It seems there are a lot of optimizations to be had then (example is returning an iolist of...

That makes sense. > So I do not see how we could deliver iolists of smaller reads. What I meant here is instead of allocating 1 large buffer (512MB), we...

> > What I meant here is instead of allocating 1 large buffer (512MB), we allocate 16kb or 160k or something, and keep > > ... > > Alright! The...

Thanks. Then it probably is not too much a difference to handle the looping/buffer-catting yourself, or use `socket` module directly to read off a gen_tcp socket with `inet_backend` set.

Using the socket module directly makes using SSL complex. And yea on the improvements I think its fine as is, the next major improvement would probably be io_uring support so...

Could this be a emulator runtime or compile time flag? I can think of a few cases where the order of atoms is very much appreciated, mostly in tooling, such...

> Future Erlang/OTP versions can reduce the size or even change the small map implementation altogether to one that does not rely on ordering. So I can understand the benefit...

This would be useful not only for TCP/Net/UDP but for filesystem reads/writes. Also it seems TCP support for IO_uring is well wired now. With modern NICS it looks like a...

> I ended up keeping existing approach. Instead of turning pid into more complex structure (by adding metadata/tag to every pid), I "tag" processes by adding them to multiple groups....

This is very interesting. hi benoitc. My main question here is receive supported and spawn?