Hello:
     To elaborate a little on what Wilfried said: 
Imagine your application running in a typical message
pump:

// Imagine this is the main loop of your app:
Procedure TMyApp.Run()
Begin
  While (ThereIsStuffToDo) Do Begin
    DoStuff();
    Application.ProcessMessages();
  End;
End;

Your application does its thing in the DoStuff()
method, and all standard house-keeping stuff is done
in ProcessMessages: button clicks, window redrawing,
component events, TCP/IP transmissions, etc.

So, as long as DoStuff() doesn't take too long, your
application remains responsive because all Windows
messages are processed quickly.

But when DoStuff() takes too long, *nothing* else is
happening.  That is, all other application and
environment events (including user input and network
communications) have to wait until it returns.

This is basically how VCL appliations work.  In the
case of ICS, network communications is handled in a
series of Windows messages and events that are
triggered when the messages are pumped from the
queue.  If one of these events, say, OnRequestDone,
executes an event handler in your application that
takes too long, the rest of the communications will
have to wait until that event handler returns.

In such cases, it is better to use a separate thread
to do the long-running process so that your
application can continue its work normally without
blocking.

Why not use threads from the beginning? Well, because
it is expensive and difficult.  It is expensive
because the operating system incurs a performance and
resource cost every time it has to instantiate a new
thread and allocate resources for it.  It is
difficult because, since they run concurrently, they
require special attention when implemented, and
communications between threads needs to be synchronized.

I hope this helps, cheers!

     -dZ.

-- 
DZ-Jay [Team ICS]
    http://www.overbyte.be/eng/overbyte/teamics.html 


>------- Original Message -------
>From    : Wilfried
Mestdagh[mailto:[EMAIL PROTECTED]
>Sent    : 11/26/2007 1:31:50 PM
>To      : twsocket@elists.org
>Cc      : 
>Subject : RE: Re: [twsocket] Design isue
>
 >Hello Albert,

You only need a threaded approach if you have to run
very long code,
meaning if your code (for example to parse incoming
data, or to get data
that need to be sent or so) is long (so blocking).

when you write code in non threading design, the time
your code is
executing nothing else will happen, meaning no data
is sent or received.
it only will happen when your code end, that is when
your application
enters the message pump.

hope this is somewhat clear.

---
Rgds, Wilfried [TeamICS]
 http://www.overbyte.be/eng/overbyte/teamics.html 
 http://www.mestdagh.biz 

Monday, November 26, 2007, 15:19, A Drent wrote:

> Until now I alway build our applications using
'normal' sockets. Currently
> I've got an application server build which is
running well for years now.
> Now I've modified the server so it is able to
process soap messages. The
> soap messages are send by the webserver to the
application server on another
> engine, parsed and executed and result is sent
back. So far so good. But I
> wonder, when do I have to use a threaded approach.
'Long' and 'blocking' as
> said in the ics sample is very vague for me. I ask
this because of a 
> possible near redesign of the server.

> Albert Drent
> University of Groningen 



-- 
To unsubscribe or change your settings for TWSocket
mailing list
please goto 
http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket

Visit our website at  http://www.overbyte.be 


-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to