Search code examples
multithreadingsocketsoperating-systemblockingnonblocking

Do my (beginner) understanding of blocking and non blocking io is correct?


Right now I do a lot of research about concurrency and parallelism. Could you tell me if I understand correctly (on os level):

Blocking io:

When I explicitly wait for connection (ie. in Ruby:)

conn = socket.accept

So my thread is blocked until I get something to socket, right?

(And I understand that I am pooling socket in some loop in accept for data, right?)

Non blocking:

I have thread that is asking from time to time all registered fd (filedescriptors) if they have something I need. But there is also 'dont call us, we will call you' rule, but how it is working on ios level (on libraries like eventmachine or node it is done by callbacks (?))

PS. I would welcome readings and presentations, like: http://www.paperplanes.de/2011/4/25/eventmachine-how-does-it-work.html http://www.kegel.com/c10k.html


Solution

  • Blocking io:

    When I explicitly wait for connection (ie. in Ruby:)

    conn = socket.accept

    So my thread is blocked until I get something to socket, right?

    Right.

    (And I understand that I am pooling socket in some loop in accept for data, right?)

    Wrong. You are blocked. Period. The operating system will wake you up when something relevant happens.

    Non blocking:

    I have thread that is asking from time to time all registered fd (filedescriptors) if they have something I need. But there is also 'dont call us, we will call you' rule, but how it is working on ios level (on libraries like eventmachine or node it is done by callbacks (?))

    What you have just described including the callbacks is 'asynchronous' I/O.

    Non-blocking I/O just means that the calls don't block, so e.g. if you call read() and there is no data already there, nothing happens. When to call the calls is up to you but it is assisted by select()/poll()/epoll(), which block until various events have occurred on the socket(s).