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
