Blocking hooks were introduced in Winsock to support Windows 3.x's non-preemptive multitasking. When an application issues a blocking sockets call, Winsock starts processing the call and then enters a loop where it alternates between calling a blocking hook and checking to see if the socket call has completed or been cancelled. The blocking hook is responsible for dispatching messages to keep the system responsive while the socket call is processing. Blocking hooks are installed on a per-thread basis.
In Win32 systems, blocking hooks aren't necessary because Win32 systems support preemptive multitasking. Consequently, Win32 versions of Winsock do not provide a default blocking hook, and using blocking hooks is discouraged. Nonetheless, an application programmer can call WSASetBlockingHook to install one.
In the OS/2 implementation of Winsock, when a call is made to a Winsock function that blocks and a blocking hook has been installed in that thread, a new thread is started to issue the socket call. The original thread then starts spinning in a loop, alternating between calling the user's blocking-hook function and checking to see if the socket call has completed or has been cancelled. A half-second sleep is inserted between each iteration of the loop to avoid consuming large amounts of CPU time. When the socket call completes, or is cancelled, the new thread passes the results of the socket call to the original thread and then ends.
When a call is made to a Winsock function that blocks and a blocking hook has not been installed for that thread, the socket call is issued directly and no threads are started.