why the cpu usage goes to 100% when the the idtcpclient connects to idtcpserver

I did a simple program that connects a component tidtcpclient to tidtcpserver, but when it connects the server, on the server side the cpu usage goes to 100%, and stay on it, so why this happaning? and this is normal? i only connected, that's it.
Who is Participating?
2266180Connect With a Mentor Commented:
I think I know what the problem is. you are not using the servers onexecute event, or are using it incorrectly.

all processing must be done in the server onexecute event using the parameter which identifies the thread (from which you get the connection object). that event is beeing executed in the context of that specific thread, so keep in mind that you will have to synchronize access to any shared resources.

if you don't want to use that event (I've had such an application myself where I just notified another thread of the existing data and the server processed it whenever it got time), you simply assign the event and in it you doo a sleep(5); (very small value).
this will make sure that :
- your server's client thread doesn't get blocked for too much time
- AND, the cpu is not used extensivly.

because what happens is that as long as there is some data to be read from the client end, the server will keep executing that event. so if you don't process data in it, it will be executed in a loop very fast ;)
TheRealLokiConnect With a Mentor Senior DeveloperCommented:
can you show us your server's code please.
I think Ciuly is right, you are probably using the OnConnect event instead of the OnExecute event.
MerijnBConnect With a Mentor Sr. Software EngineerCommented:
alternatively, if you are not familiar with sync programming, use something like ICS (free): http://www.overbyte.be/frame_index.html?redirTo=/products/ics.html
(this is an addition/extension to merijnb's post)

it's not really sycn programming. indy uses blocking (synchronous) sockets whereas ics uses non-blocking (asyncronous) sockets. so it's not the programming style but the socket type. and in both cases, the basic style is to use events, the difference is the way those events are fired and processed. and of course that the socket type induces a certain programming style, but I for example have made 2 systems until today that can use blocking sockets in a non-blocking fashion. of course, the unrelying atomic data is a (n xml) command so the event is fired when such a command is available to be processed.
what I want to say is that no matter of the socket type you can use any programming style, but you'll just have to be carefull :)

basically, both types of sockets are best fit for specific types of applications (complementary). and as I said above, both types of sockets can be used in the other types of applications where they don't fit so well.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.