Unexpected 'Error during req_read' from pico

[kpeters58]

Describe the bug

Reproduction Steps

Tested the throughput of vweb/pico using Bomardier.

Built an exe from https://github.com/vlang/v/blob/master/examples/pico/pico.v (using tcc)

Tested with various connection counts (Bombardier's 'c' parameter) and the exe reports one req_read error for every connection, i.e, 5 errors for 5 connections, 20 for 20 connections and so forth.

Expected Behavior

To see Bombardier finish without pico emitting any error messages.

Current Behavior

Exe emits one 'Error during req_read' per connection

Possible Solution

---

Additional Information/Context

---

V version

0.4.5 2baa11b

Environment details (OS name and version, etc.)

Win11 Pro

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[4kbyte]

Same issue on Linux with v run pico.v and siege http://localhost:8089.

Note that the benchmark reports the server as online without dropping any requests.

Printing the server response in the benchmark shows that the server is replying as expected, even when reporting Error during req_read internally:

# sample response from:
# siege --print --concurrent=10 --reps=100 http://localhost:8089

GET / HTTP/1.0
Host: localhost:8089
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (pc-x86_64-linux-gnu) Siege/4.1.6
Connection: close


Hello Picoev!

Increasing to 20k requests (20x1000 on a 24-core machine) sometimes shows something like this at the end of log output:

Error during req_read
Error during accept
Error during req_read
Error during req_read
Error during accept
Error during accept
Error during accept
Error during accept
Error during accept
Error during accept
Error during accept
Error during req_read
Error during req_read

Again, all requests are successful in the benchmark.

The underlying issue is that C recv and accept calls can reply with EAGAIN or EWOULDBLOCK on a -1 return value, which is to be expected for the asynchronous picoev event loop server.

The fix is to continue silently in the cases of EAGAIN or EWOULDBLOCK.

Patch incoming.

---

V 0.4.5 6a6d8e0