Does Phoenix have non blocking I/O?

[alebian]

Hi,

I have a simple question but I am not being able to find resources about it. I want to build a gateway with Phoenix and for simplicity I want it to wait for the response on the other servers. For that reason I want to know if Phoenix uses non blocking I/O.

Thanks

[AstonJ]

You might find this thread interesting:

Non-Blocking IO

Hi everyone, I’m about to start a big project, a server application for a certain game, and i need to build a non-blocking IO functionality to listen connection and receive packets. What should i know to build this functionallity? There is some lib that already do this ? There is some lib (ex: mongodb, redis) that implement this, so i can read and learn how to do ? Thanks.

[alebian]

TL;DR
The answer is yes.
After reading that thread, since Phoenix uses cowboy and cowboy uses ranch, it basically has non blocking IO.

Thanks

[peerreynders]

@alebian

simplicity I want it to wait for the response on the other servers. For that reason I want to know if Phoenix uses non blocking I/O

I’m finding this question confusing - as stated it sounds like you want to avoid the “complexity” having to manage non-blocking/asynchronous I/O yourself which, because of the BEAM’s runtime model, Phoenix allows you to do.

[benwilson512]

Close. all IO conducted by separate processes is non blocking because of how the BEAM itself works, regardless of whether you’re using cowboy or ranch. Ranch handles each HTTP request in its won process, so consequently all the IO done by an HTTP request is non blocking with respect to other processes.

[OvermindDL1]

@benwilson512

Close. all IO conducted by separate processes is non blocking because of how the BEAM itself works, regardless of whether you’re using cowboy or ranch. Ranch handles each HTTP request in its won process, so consequently all the IO done by an HTTP request is non blocking with respect to other processes.

This. All IO on the BEAM is non-blocking, that’s just how it works. Now some interfaces to the IO may serialize on messages, but even that is optional as by default all IO is via messages that you handle however you want. Something like Ranch will spawn a new greenthread (BEAM Process) to handle each IO connection for example, but you could easily just handle many connections in a single greenthread too, or handle each individual message in a process, or distribute it out to multiple computers, or whatever.