Thread Pool vs Evented IO

[ysbaddaden]

Thread Pool vs Evented IO

[ysbaddaden]

This is tied to what Crystal comes up with. The threaded version was quick to develop.

Attemtps to use the libuv based IO model of Crystal didn't go that well for now —it requires to drop the IO.select loops, to find a way around File#reopen (libuv doesn't wrap dup, dup2 or dup3), and certainly more.

This is a long term ticket, to keep up with whatever concurrency/parallelism scheme Crystal thrives for.

[ysbaddaden]

Note that since #8 Prax uses a thread pool (fixed to 16) instead of spawning a thread to handle each connection.

[ysbaddaden]

Crystal 0.7.0 initiated the move to evented IO by default, and Prax now takes advantage of it since 261f119.

Server sockets (HTTP or HTTPS) are each handled in their own fiber, avoiding the need for IO.select; and client sockets are each handled in their own fiber too (unlimited) to avoid blocking the HTTP[S] servers. Let's see how it goes!

[asterite]

That's the spirit!! :-) :-) :-)

[ysbaddaden]

A part of me would like to keep control over what runs in parallel, but another part just want Erlang actors and not bother with concurrent vs parallel. I wish crystal will allow just that.