This refers to blocking sockets or blocking function calls.
I attached a description of the problem.
Cheers,
Peter
On Tue, 13 Jun 2006 12:44:03 +0200, DZ-Jay <[EMAIL PROTECTED]> wrote:
Hello:
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,
dZ.
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
Ercan POLAT
http://www.developerfusion.co.uk/show/28/8/
Author
Catalyst Development
Blocking vs. Non-Blocking Sockets
One of the first issues that youll 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
read.
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
application.
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, its 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 http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
