IO devices and operating systems communicate via data packets known as IO requests. When an IO device makes a request an application can respond in one of two ways: blocking, and non-blocking.
Most IO requests are considered blocking requests. When the IO makes a request, an application typically cannot continue executing other requests until it has the necessary information changes from the IO. Therefore, blocking calls requires a process to stop and wait for input/output. Consider a word processing software - when we have a new document open, the application halts while waiting for the user to type some words.
Non-blocking requests get placed into a queue while waiting so that the CPU resources can be used to complete other tasks in an event pool. The event pool is the queue mentioned earlier. IO device responses can be handled later, as long as the request has been acknowledged by the OS. Non-blocking is also commonly referred to as asynchronous. Think about a collaborative application in which there are multiple requests being made by different users simultaneously. The application does not halt for every user each time it is waiting for some input from a single user.
Take a look at the animation. It provides a real-life example as an analogy of blocking vs non-blocking.
The left side of the image shows us how blocking works - because one employee is handling all orders, the other customers must wait for their request to be processed while the previous request is being completed. The right side of the animation is an example of non-blocking - having two employees working allows for one to receive requests from customers, while the other employee processes them.