This refers to blocking sockets or blocking function calls.
I attached a description of the problem.


On Tue, 13 Jun 2006 12:44:03 +0200, DZ-Jay <[EMAIL PROTECTED]> wrote:

        I received this question directly from an ICS user.  I suggested he
subscribe to this list, but in the meantime, can anybody shed some
light on the problem stated?

        Thank you,

On Jun 13, 2006, at 03:11, AKINSOFT Programlama wrote:

Hi Jaime

I am using ICS's Ftp Server component and I get "operation would block"
message from my application
on some computers ( my application is a cafe control software). How can
I solve this problem.
( I cant get good information about this error message on message
boards so I ask this you, Sorry :)

Thank You


Catalyst Development

Blocking vs. Non-Blocking Sockets

One of the first issues that you’ll encounter when developing your Windows 
Sockets applications is the difference between blocking and non-blocking 
sockets. Whenever you perform some operation on a socket, it may not be able to 
complete immediately and return control back to your program. For example, a 
read on a socket cannot complete until some data has been sent by the remote 
host. If there is no data waiting to be read, one of two things can happen: the 
function can wait until some data has been written on the socket, or it can 
return immediately with an error that indicates that there is no data to be 

The first case is called a blocking socket. In other words, the program is 
"blocked" until the request for data has been satisfied. When the remote system 
does write some data on the socket, the read operation will complete and 
execution of the program will resume. The second case is called a non-blocking 
socket, and requires that the application recognize the error condition and 
handle the situation appropriately. Programs that use non-blocking sockets 
typically use one of two methods when sending and receiving data. The first 
method, called polling, is when the program periodically attempts to read or 
write data from the socket (typically using a timer). The second, and preferred 
method, is to use what is called asynchronous notification. This means that the 
program is notified whenever a socket event takes place, and in turn can 
respond to that event. For example, if the remote program writes some data to 
the socket, a "read event" is generated so that program knows it can read the 
data from the socket at that point.

For historical reasons, the default behavior is for socket functions to "block" 
and not return until the operation has completed. However, blocking sockets in 
Windows can introduce some special problems. For 16-bit applications, the 
blocking function will enter what is called a "message loop" where it continues 
to process messages sent to it by Windows and other applications. Since 
messages are being processed, this means that the program can be re-entered at 
a different point with the blocked operation parked on the program's stack. For 
example, consider a program that attempts to read some data from the socket 
when a button is pressed. Because no data has been written yet, it blocks and 
the program goes into a message loop. The user then presses a different button, 
which causes code to be executed, which in turn attempts to read data from the 
socket, and so on.

Blocking socket functions can introduce a different type of problem in 32-bit 
applications because blocking functions will prevent the calling thread from 
processing any messages sent to it. Since many applications are 
single-threaded, this can result in the application being unresponsive to user 
actions. To resolve the general problems with blocking sockets, the Windows 
Sockets standard states that there may only be one outstanding blocked call per 
thread of execution. This means that 16-bit applications that are re-entered 
(as in the example above) will encounter errors whenever they try to take some 
action while a blocking function is already in progress. With 32-bit programs, 
the creation of worker threads to perform blocking socket operations is a 
common approach, although it introduces additional complexity into the 

The SocketWrench control facilitates the use of non-blocking sockets by firing 
events. For example, a Read event is generated whenever the remote host writes 
on the socket, which tells your application that there is data waiting to be 
read. The use of non-blocking sockets will be demonstrated in the next section, 
and is one of the key areas in which a control has a distinct advantage over 
coding directly against the Windows Sockets API.

In summary, there are three general approaches that can be taken when building 
an application with the control in regard to blocking or non-blocking sockets: 
Use a blocking (synchronous) socket. In this mode, the program will not resume 
execution until the socket operation has completed. Blocking sockets in 16-bit 
application will allow it to be re-entered at a different point, and 32-bit 
applications will stop responding to user actions. This can lead to complex 
interactions (and difficult debugging) if there are multiple active controls in 
use by the application.
Use a non-blocking (asynchronous) socket, which allows your application to 
respond to events. For example, when the remote system writes data to the 
socket, a Read event is generated for the control. Your application can respond 
by reading the data from the socket, and perhaps send some data back, depending 
on the context of the data received.
Use a combination of blocking and non-blocking socket operations. The ability 
to switch between blocking and non-blocking modes "on the fly" provides a 
powerful and convenient way to perform socket operations. Note that the warning 
regarding blocking sockets also applies here.

If you decide to use non-blocking sockets in your application, it’s important 
to keep in mind that you must check the return value from every read and write 
operation, since it is possible that you may not be able to send or receive all 
of the specified data. Frequently, developers encounter problems when they 
write a program that assumes a given number of bytes can always be written to, 
or read from, the socket. In many cases, the program works as expected when 
developed and tested on a local area network, but fails unpredictably when the 
program is released to a user that has a slower network connection (such as a 
serial dial-up connection to the Internet). By always checking the return 
values of these operations, you insure that your program will work correctly, 
regardless of the speed or configuration of the network.
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to