#Non blocking I/O
25 messages · Page 1 of 1 (latest)
@azure gyro It doesn't "trigger". You explicitly call epoll_wait on the thread and the OS will then either give you the events that happened (which you can then process at your own pace) or it will hang at epoll_wait waiting for the next event
It's "non-blocking" because while you can receive I/O events while your code is still executing, the OS will just give them later when you call epoll_wait
Ohh so the reactive frameworks out there handles these system calls
Like they itself call epoll_wait() ?
Do you have a flow diagram or something for non blocking I/o ?
So that I could understand the whole process completely?
I have terrifyingly bad drawing skills
But basically if you remember, if you use read() or write() your process would block until the I/O operations are complete, which usually takes significantly longer right?
Yes
Non-blocking IO kinda means you give a command to the OS, ignores it, and then later just check with the OS if it has completed or not
Your code runs and doesn't have to care/block immediately about if the I/O operations have succeeded or not
It's this way because relative to execution speed, I/O is slow, so waiting around for it is dumb
Suppose there is a network call and it's non blocking. The rest of the code will be executed or function will return. In the background, the framework issues epoll_wait() for this network I/o. So once it's done the os will be notified and the data shall be returned. Is it right?
@azure gyro It's kinda difficult to imagine but to your process it will still look as if it's blocking
epoll_wait() will still hang the thread
So what will make that thread free?
What is asynchronous/non-blocking is that between epoll_ctl (issuing the I/O operation) and epoll_wait you're free to do whatever you want
You only epoll_wait when you actually wanted to
Unlike blocking I/O where the moment you issue an operation you have to wait for it to complete before any other code in the flow would run
@brisk narwhal A file descriptor is said to be io ready if any io operation could be performed without blocking. So how is it determined whether a file descriptor is ready or not?
Are there any other things done by kernel or os for this?
"Without blocking" here means more if you perform an I/O operation it would be processed right away without waiting for any other thing to complete