epoll only notifies you that an specific fd is able to receive data, or has data to read. then reading from non-blocking socket or writing into it doesnt block your execution or waits til data is transfered.

reading in blocking IO result in: if data is available your buffer is filled with data, otherwise thread goes to sleep til data is available or a failure detected

writing in blocking IO result in: if able to write, then you write and thread goes to sleep til data is written, otherwise thread goes to sleep til able to write

but in non-blocking IO, thread never goes to sleep, you only receive notification of availibility for reading and writing for specific fd. and for detecting "its enough to read or write", read or write will return -1 and errno is set to EAGAIN or EWOULDBLOCK.

dont worry about errno, its per thread, your execution wont mess.

reading or writing is the same for kenel in any situation, no matter its blocking or non-blocking. its all about reducing number of context switiching by reducing number of threads. hence you receive more performance.

when you are in a situation you need to do any async task, you need more playing with states than doing traditional jobs.

for example:

in a blocking IO for parsing http requests you read as much as a full http header is parsed then step into next phase. parsing in blocking IO is easy, because you dont miss which part of your parsing phase you were, as you dont leave that part.

but the game in non-blocking IO is different, because everytime you receive a partial data, consider receiving data as below: first

GET /

then

index.php http/1.1

then

\r\n\r\n

so how do you parse that data?

you have two choices:

1. store as much in a cache til you receive double \r\n\r\n then parse with your previous algorithm

2. start parsing from a previous stored state, if done return, if not, store state for next data arrival ...

receiving data in partial as above is a rare case, but in busy networks with some custom configs you will face such a case.

but the problem is not parsing headers, its all about you have to do everything in partial as your data is ready partially. so you need to store states of the place you previously were in, for any connection.

so when you are doing non-blocking IO, no matter you are doing all things in one thread or pass to other threads to do stuffs, anyway you are lost in lots of partially done stuffs.

so you need to properly store states of anything, yes anything. and continue from that state. and that makes your code more complicated as the problem is complicated.

we wait for another nginx with more performance from you ;)

epoll only notifies you that an specific fd is able to receive data, or has data to read. then reading from non-blocking socket or writing into it doesnt block your execution or waits til data is transfered.

reading in blocking IO result in: if data is available your buffer is filled with data, otherwise thread goes to sleep til data is available or a failure detected

writing in blocking IO result in: if able to write, then you write and thread goes to sleep til data is written, otherwise thread goes to sleep til able to write

but in non-blocking IO, thread never goes to sleep, you only receive notification of availibility for reading and writing for specific fd. and for detecting "its enough to read or write", read or write will return -1 and errno is set to EAGAIN or EWOULDBLOCK.

dont worry about errno, its per thread, your execution wont mess.

reading or writing is the same for kenel in any situation, no matter its blocking or non-blocking. its all about reducing number of context switiching by reducing number of threads. hence you receive more performance.

when you are in a situation you need to do any async task, you need more playing with states than doing traditional jobs.

for example:

in a blocking IO for parsing http requests you read as much as a full http header is parsed then step into next phase. parsing in blocking IO is easy, because you dont miss which part of your parsing phase you were, as you dont leave that part.

but the game in non-blocking IO is different, because everytime you receive a partial data, consider receiving data as below:

first

GET /

then

index.php http/1.1

then

\r\n\r\n

so how do you parse that data?

you have two choices:

1. store as much in a cache til you receive double \r\n then parse with your previous algorithm

2. start parsing from a previous stored state, if done return, if not, store state for next data arrival ...

receiving data in partial as above is a rare case, but in busy networks with some custom configs you will face such a case.

but the problem is not parsing headers, its all about you have to do everything in partial as your data is ready partially. so you need to store states of the place you previously were in, for any connection.

so when you are doing non-blocking IO, no matter you are doing all things in one thread or pass to other threads to do stuffs, anyway you are lost in lots of partially done stuffs.

so you need to properly store states of anything, yes anything. and continue from that state. and that makes your code more complicated as the problem is complicated.

we wait for another nginx with more performance from you ;)

epoll only notifies you that an specific fd is able to receive data, or has data to read. then reading from non-blocking socket or writing into it doesnt block your execution or waits til data is transfered.

reading in blocking IO result in: if data is available your buffer is filled with data, otherwise thread goes to sleep til data is available or a failure detected

writing in blocking IO result in: if able to write, then you write and thread goes to sleep til data is written, otherwise thread goes to sleep til able to write

but in non-blocking IO, thread never goes to sleep, you only receive notification of availibility for reading and writing for specific fd. and for detecting "its enough to read or write", read or write will return -1 and errno is set to EAGAIN or EWOULDBLOCK.

dont worry about errno, its per thread, your execution wont mess.

reading or writing is the same for kenel in any situation, no matter its blocking or non-blocking.

when you are in a situation you need to do any async task, you need more playing with states than doing traditional jobs.

for example:

in a blocking IO for parsing http requests you read as much as a full http header is parsed then step into next phase. parsing in blocking IO is easy, because you dont miss which part of your parsing phase you were, as you dont leave that part.

but the game in non-blocking IO is different, because everytime you receive a partial data, consider receiving data as below: first

GET /

then

index.php http/1.1

then

\r\n\r\n

so how do you parse that data?

you have two choices:

1. store as much in a cache til you receive double \r\n\r\n then parse with your previous algorithm

2. start parsing from a previous stored state, if done return, if not, store state for next data arrival ...

receiving data in partial as above is a rare case, but in busy networks with some custom configs you will face such a case.

but the problem is not parsing headers, its all about you have to do everything in partial as your data is ready partially. so you need to store states of the place you previously were in, for any connection.

so when you are doing non-blocking IO, no matter you are doing all things in one thread or pass to other threads to do stuffs, anyway you are lost in lots of partially done stuffs.

so you need to properly store states of anything, yes anything. and continue from that state. and that makes your code more complicated as the problem is complicated.

we wait for another nginx with more performance from you ;)

epoll only notifies you that an specific fd is able to receive data, or has data to read. then reading from non-blocking socket or writing into it doesnt block your execution or waits til data is transfered.

reading in blocking IO result in: if data is available your buffer is filled with data, otherwise thread goes to sleep til data is available or a failure detected

writing in blocking IO result in: if able to write, then you write and thread goes to sleep til data is written, otherwise thread goes to sleep til able to write

but in non-blocking IO, thread never goes to sleep, you only receive notification of availibility for reading and writing for specific fd. and for detecting "its enough to read or write", read or write will return -1 and errno is set to EAGAIN or EWOULDBLOCK.

dont worry about errno, its per thread, your execution wont mess.

reading or writing is the same for kenel in any situation, no matter its blocking or non-blocking. its all about reducing number of context switiching by reducing number of threads. hence you receive more performance.

when you are in a situation you need to do any async task, you need more playing with states than doing traditional jobs.

for example:

in a blocking IO for parsing http requests you read as much as a full http header is parsed then step into next phase. parsing in blocking IO is easy, because you dont miss which part of your parsing phase you were, as you dont leave that part.

but the game in non-blocking IO is different, because everytime you receive a partial data, consider receiving data as below: first

GET /

then

index.php http/1.1

then

\r\n\r\n

so how do you parse that data?

you have two choices:

1. store as much in a cache til you receive double \r\n\r\n then parse with your previous algorithm

2. start parsing from a previous stored state, if done return, if not, store state for next data arrival ...

receiving data in partial as above is a rare case, but in busy networks with some custom configs you will face such a case.

but the problem is not parsing headers, its all about you have to do everything in partial as your data is ready partially. so you need to store states of the place you previously were in, for any connection.

so when you are doing non-blocking IO, no matter you are doing all things in one thread or pass to other threads to do stuffs, anyway you are lost in lots of partially done stuffs.

so you need to properly store states of anything, yes anything. and continue from that state. and that makes your code more complicated as the problem is complicated.

we wait for another nginx with more performance from you ;)