When attempting to perform a network operation, such as sending or receiving data, it fails with an error indicating that a blocking operation is in progress.
There can only be one blocking socket operation per thread for a given process. While an application is blocked waiting for a socket operation to complete, such as calling the Read method and waiting for data to arrive, Windows messages may be processed. In turn, this may cause the application to be re-entered in the same thread. An example would be a Timer event which fires periodically. If the application attempts to perform another socket operation while a blocking operation is already in progress, error 10036 will be returned. The error should be considered advisory, and the application should retry the operation again at some later point.
It is also possible for non-blocking sockets to return this error when reading or writing data if a blocking operation is performed in the OnRead or OnWrite event handler. Server applications may also encounter this error when accepting client connections in the OnAccept event. One example of this would be performing a reverse DNS lookup, attempting to resolve an IP address into a hostname, while inside the OnAccept event.
It is recommended that applications which use non-blocking sockets do not set the AutoResolve property to True. For SocketWrench 3.6 or earlier versions, the AutoResolve property should be explicitly set to False prior to establishing or accepting a connection. Avoid using the HostName or PeerName properties inside event handlers, since this can cause the control to perform reverse DNS lookups which can block the current thread. Instead, use the HostAddress and PeerAddress properties to obtain the IP address.
To determine if a blocking operation is in progress, check the value of the IsBlocked property. A value of True indicates that the application is currently blocked. A value of False indicates that there is no blocking operation at that time. It is important to note however that a value of False does not guarantee that the next method or function call will not return an error. An application should never solely depend on the value of the IsBlocked property to determine if a subsequent socket operation will succeed or fail.