On Wednesday, 15 November 2017 at 23:04:46 UTC, kdevel wrote:
On Wednesday, 15 November 2017 at 13:31:46 UTC, Daniel Kozak
wrote:
This one works ok for me, but I am on linux:
https://dpaste.dzfl.pl/f54decee45bc
It works, but it does not handle two connects in parallel. STR:
1. start the binary in console 1
2. telnet localhost 4444 in console 2
3. telnet localhost 4444 in console 3
4. enter a [RETURN] in console (3)
observed: nothing (the "thread" handling the first connect
blocks)
expected: response
On my machine defaultPoolThreads() returns 1. This can easily
be increased:
```
defaultPoolThreads(8);
```
There is also another problem with Socket.select: It may return
-1. This frequently happens when the ACCEPT socket is
non-blocking and the select is interrupted (by the GC?) then
errno == EINTR.
Also not having a timeout in the Socket.select of handle_socket
allows for DOS attacks like the one above. In case of a timeout
select also returns -1.
Hi Guys,
so i have tried the latest changes with destroy(socket) rather
than socket.close().
Still the program is extremely slow.
I see that the httpclinet is making successfully 100 request at a
time and then it freezes for 5/10 seconds and then it process
another 100 request.
As Kdevel pointed out, this could be related to the Socket.select
blocking on the interupt or it would be GC kicking in.
I also have seen the value computed for the defaultThread is not
correct, hence i manually started the TaskPool(int thread)
manually.
I'm going to share my benchmark program so you can guys test with
the same tool.
Unfortunately it seems that there is some underline issue which
is blocking the program and preventing to process all the
incoming requests in a performant fashion, or at-least utilising
the full CPU cycles.
reagrds
ade90036
