Why TCP connections must be handled concurrently

[KawaiiZapic]

From #715, I still didn't get why TCP connections must be handled concurrently.

const encoder = new TextEncoder();
const sleep = (ms) => new Promise(res => { setTimeout(() => res(), ms); });

/** @type {tjs.Listener} */
const server = await tjs.listen("tcp", "127.0.0.1", 3000, {
  backlog: 1
});

while (true) {
  const conn = await server.accept();
  await sleep(100);
  await conn.write(encoder.encode("HTTP/1.1 200 OK\r\nConnection: close\r\nContent-Length: 11\r\n\r\nHello world"));
  conn.close();
}

As the code telling, the server will tell Chrome "don't keep tcp connection alive" and close the connection after data sent, server should be ready for next connection. But this simple HTTP server will stcuk at server.accept after accepted a connection from Chrome.
I write a (maybe just looks like) same thing in Python3, and it just working fine.

import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(("127.0.0.1", 3001))
s.listen(1)

while True:
    c, addr = s.accept()
    time.sleep(0.1)
    c.send(b"HTTP/1.1 200 OK\r\nConnection: close\r\nContent-Length: 11\r\n\r\nHello world")
    c.close()

I do not know much about network things, is there anything I missing out?

[bnoordhuis]

Works for me. Does making requests with curl instead of chrome work? Note that you don't read the request, so who is to say there's someone on the other end reading?

One gotcha with chrome is that it often makes multiple simultaneous connections to the same domain for performance reasons, without necessarily reading or writing data on those extra connections (only if there are more resources to fetch, like css or script files.)

[KawaiiZapic]

Works for me. Does making requests with curl instead of chrome work? Note that you don't read the request, so who is to say there's someone on the other end reading?

One gotcha with chrome is that it often makes multiple simultaneous connections to the same domain for performance reasons, without necessarily reading or writing data on those extra connections (only if there are more resources to fetch, like css or script files.)

It works when making request from curl, but this does not explain why same code works in Python but not in JS.
I take a look at the network panel in Chrome devtools, it does send two requests to server simultaneously: / by I typed in URL bar, and /favicon.ico by Chrome itself.
Requests send to JS server and Python server is exactly same, so I'm really confused what happend under those less than 10 lines code.

[partic2]

This is a issue about accepted socket missing.

txiki.js/src/mod_streams.c

Lines 363 to 376 in e359e5e

	int r = uv_accept(handle, &t2->h.stream);
	if (r != 0) {
	JS_FreeValue(ctx, arg);
	arg = tjs_new_error(ctx, r);
	is_reject = 1;
	}
	} else {
	arg = tjs_new_error(ctx, status);
	is_reject = 1;
	}
	TJS_SettlePromise(ctx, &s->accept.result, is_reject, 1, &arg);
	TJS_ClearPromise(ctx, &s->accept.result);
	}

I have fixed it in my fork.
https://github.com/partic2/txiki.js-partic
But there is still a PR I made is not merged. which I want to 'diff' with.
Also I haven't well tested these patch yet