Hi cpu usage

hi
i have been working on common libraryfor setting up server and acing a big
problem that whenever i run my server then either core of my cpu have 100%
usage.
I know this is happening because there is a infinite loop in my threads.

void * main_thread(void * data)
{
int flag=1,choice,n;
int temp;
TCPsocket client_socket,server_socket;
if(!child_intialize_thread())
{
printf("\n There is some error while initializing thread");
return 0;
}
printf("\n Value of active ports is:%d",child_active_ports);

// first server receive request from client to connect and open master

server socket. To be created only once.-permanent
if(common_connect_server(&host_ipaddress,&server_socket,2000,(const char
*)NULL)==0)
return (void *)1;
while(quit)

{
//from here main problem starts i have to keep it in while loop so that it
can accept
if((client_socket=SDLNet_TCP_Accept(server_socket)))

{
// connect to different clients so that it can work as concurrent server. Is
there any way

pthread_mutex_lock(&child_mutex_variable);
// is there any other way to do it and avoid high cpu usage.
printf("\n Value of active ports:%d",child_active_ports);
if(child_active_ports==0)
{
int temp=0;
SDLNet_TCP_Send(client_socket,&(temp),2);
SDLNet_TCP_Close(client_socket);
pthread_mutex_unlock(&child_mutex_variable);
}
else
{
pthread_mutex_unlock(&child_mutex_variable);
printf("\n Activating thread");
activate_thread(client_socket);
}
}
}
printf("\nEverything is OK now exiting");
SDLNet_TCP_Close(server_socket);
cleanup_thread();
return NULL;
}

When you say “infinite loop” do you mean that you called a function and it
never returns but uses 100% CPU?
Is your socket set up as blocking?

Patrick

No one of thread have infinite loop. I solve it by using nanosleep()
function.
Thank’s four replyingOn 12-Mar-2011 8:50 PM, “Patrick Baggett” <baggett.patrick at gmail.com> wrote:

When you say “infinite loop” do you mean that you called a function and it
never returns but uses 100% CPU?
Is your socket set up as blocking?

Patrick

No one of thread have infinite loop. I solve it by using nanosleep() function.
Thank’s four replying

Since SDLNet_TCP_Accept() is a non blocking call, that’s a bandaid on your
bug. The loop is still there, and nanosleep could also be a busy loop on some
platforms.

A proper fix would be to use SDLNet_CheckSockets().

Regards,
Frank.On 03/12/2011 09:32 AM, deepak aggarwal wrote:

On 12-Mar-2011 8:50 PM, “Patrick Baggett” <baggett.patrick at gmail.com <mailto:baggett.patrick at gmail.com>> wrote:

When you say “infinite loop” do you mean that you called a function and it
never returns but uses 100% CPU?
Is your socket set up as blocking?

Patrick


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

No one of thread have infinite loop. I solve it by using nanosleep() function.
Thank’s four replying

Since SDLNet_TCP_Accept() is a non blocking call, that’s a bandaid on your
bug. The loop is still there, and nanosleep could also be a busy loop on some
platforms.

A proper fix would be to use SDLNet_CheckSockets().

A proper fix is to use a real networking library, not SDL.

For message passing use ZeroMQ. For streaming I don’t know, you’ll
usually need UDP.

In Felix we have our own library, we’re using poll/epoll/kqueue with async I/O,
this blocks until a socket is ready which is what you want in an I/O thread.On 13/03/2011, at 3:01 AM, Frank Zago wrote:

On 03/12/2011 09:32 AM, deepak aggarwal wrote:


john skaller
@john_skaller

No one of thread have infinite loop. I solve it by using nanosleep()
function.

Thank’s four replying

Since SDLNet_TCP_Accept() is a non blocking call, that’s a bandaid on
your
bug. The loop is still there, and nanosleep could also be a busy loop on
some
platforms.

A proper fix would be to use SDLNet_CheckSockets().

A proper fix is to use a real networking library, not SDL.

For message passing use ZeroMQ. For streaming I don’t know, you’ll
usually need UDP.

In Felix we have our own library, we’re using poll/epoll/kqueue with async
I/O,
this blocks until a socket is ready which is what you want in an I/O
thread.


john skaller
skaller at users.sourceforge.net
HI john


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
On Sun, Mar 13, 2011 at 12:42 AM, john skaller < skaller at users.sourceforge.net> wrote:
On 13/03/2011, at 3:01 AM, Frank Zago wrote:

On 03/12/2011 09:32 AM, deepak aggarwal wrote:

No one of thread have infinite loop. I solve it by using nanosleep()
function.

Thank’s four replying

Since SDLNet_TCP_Accept() is a non blocking call, that’s a bandaid on
your
bug. The loop is still there, and nanosleep could also be a busy loop on
some
platforms.

A proper fix would be to use SDLNet_CheckSockets().

A proper fix is to use a real networking library, not SDL.

For message passing use ZeroMQ. For streaming I don’t know, you’ll
usually need UDP.

In Felix we have our own library, we’re using poll/epoll/kqueue with async
I/O,
this blocks until a socket is ready which is what you want in an I/O
thread.


john skaller

Hi John
You are write that we need some function that put a thread in IO queue and
keep in waiting state till it get input but still there is no function
provided
in SDL library and i am working on libraries that are to be highly cross
platform and based on SDL_net library. So it will noe be possible to use a
platform specific networking library.
On blogs i have read that this type of interrupt can be obtained by using
assembly code and then using it into our code but i don’t know how to
implement.
Can any one help me to get it solve or else i have to use time based
interrupt to solve high CPU consumption.On Sun, Mar 13, 2011 at 1:24 AM, deepak aggarwal <@deepak_aggarwal wrote:
On Sun, Mar 13, 2011 at 12:42 AM, john skaller < skaller at users.sourceforge.net> wrote:

On 13/03/2011, at 3:01 AM, Frank Zago wrote:

On 03/12/2011 09:32 AM, deepak aggarwal wrote:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi John
You are write that we need some function that put a thread in IO queue and keep in waiting state till it get input but still there is no function provided
in SDL library

That’s why you need a real networking library. Libs like ZeroMQ are likely
to be more cross platform and more robust than anything SDL has to offer.

This isn’t a criticism of the SDL authors: cross platform high performance
"actually working" networking code is quite hard, so SDL just provides some
basic stuff.

Note that TCP/IP is basically a useless protocol, its very badly designed.
You really NEED something like ZeroMQ to add a message passing layer
properly.On 13/03/2011, at 7:01 AM, deepak aggarwal wrote:


john skaller
@john_skaller

Wish they will make it more robust in near future.
But can you help me to find fix for it, might be assembly code which will
put thread in waiting queue(I/O) .

Hi John
You are write that we need some function that put a thread in IO queue
and keep in waiting state till it get input but still there is no function
provided

in SDL library

That’s why you need a real networking library. Libs like ZeroMQ are likely
to be more cross platform and more robust than anything SDL has to offer.

This isn’t a criticism of the SDL authors: cross platform high performance
"actually working" networking code is quite hard, so SDL just provides
someOn 13-Mar-2011 2:34 PM, “john skaller” wrote:
On 13/03/2011, at 7:01 AM, deepak aggarwal wrote:
basic stuff.

Note that TCP/IP is basically a useless protocol, its very badly designed.
You really NEED something like ZeroMQ to add a message passing layer
properly.


john skaller
skaller at users.sourceforge.net


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is the funniest thing I’ve read today.On Sun, 13 Mar 2011 20:04:36 +1100 john wrote:

Note that TCP/IP is basically a useless protocol, its very badly
designed.

wut?
care to elaborate?On Sun, Mar 13, 2011 at 10:04 AM, john skaller wrote:

Note that TCP/IP is basically a useless protocol, its very badly designed.

+1 :smiley:

Still, it’s served me and my former employer and countless others well for
ages - but then again, where do you draw the line between working with and
working around an API…?On Sunday 13 March 2011, at 12.09.32, Tim Angus wrote:

On Sun, 13 Mar 2011 20:04:36 +1100 john wrote:

Note that TCP/IP is basically a useless protocol, its very badly
designed.

This is the funniest thing I’ve read today.


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

I think what skaller is trying to say is that UDP is a faster protocol.

Regardless SDL has a great networking interface, but most people don’t like
it because it is as low-level as you can get before heading into assembly.
It is up to developers like us to write wrappers around those protocols to
suit our needs.

If you’re not concerned about speed, and you want a reliable connection, TCP
is the way to go. There are wrappers around the UDP to check and keep a
certain level of reliablility (enet has a good UDP interface, for instance).

Games, generally speaking, use a combination of TCP and UDP sockets to keep
a connection to a server and to send data as fast as possible.
I usually use TCP for checking if a connection is still valid and any
text/string chat system, and UDP to send user states (As these need to be
updated a little more quickly). You could probably google for some good
game networking theory to get more information.

-OzOn Sun, Mar 13, 2011 at 8:19 AM, David Olofson wrote:

On Sunday 13 March 2011, at 12.09.32, Tim Angus wrote:

On Sun, 13 Mar 2011 20:04:36 +1100 john wrote:

Note that TCP/IP is basically a useless protocol, its very badly
designed.

This is the funniest thing I’ve read today.

+1 :smiley:

Still, it’s served me and my former employer and countless others well for
ages - but then again, where do you draw the line between working with
and
working around an API…?


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

But taking things out of context is so fun! :slight_smile:

On a more serious note, I have found TCP suboptimal for a certain usage case - realtime streaming with exact bandwidth limiting and lowest-possible-latency packet loss recovery.

When I added in-game streaming downloads to my quake engine, I did it using UDP with an extremely basic (offset, size) header and simply have the recipient echoing back the headers, the sender notices
if the last acknowledged offset+size does not match the expected new offset value, and if so it rewinds the send offset to the expected position it was waiting for (keeping in mind that several
packets have already been sent in the interim, this is indeed a rewind).

Some interesting characteristics of this approach compared to TCP:

  1. Bandwidth available must be known in advance (unlike TCP), exceeding available bandwidth has extremely bad side effects (high packet loss, high latency).
  2. Send/Receive bandwidth can be exactly specified by users and negotiated between client/server (with TCP any attempt to throttle is somewhat of a guess, and doing so in both directions is a rare
    feature indeed).
  3. Rapid small packets are viable at any latency (with TCP the maximum packet frequency is dependent on ping time because it only allows a certain number of in-flight packets at once).
  4. A simple packet-loss tolerance method can be implemented by duplicating data - this is primarily of interest for realtime player input (where high latency and minor packet loss must be tolerated
    without stalling, while still guaranteeing eventual delivery in cases of extreme packet loss).
  5. Real-world packet size is limited (to about 1400-1500 bytes depending on how lucky you’re feeling with tunnel overhead and MaxMTU values), but frequency can be very high (as long as you can keep
    the socket busy).
  6. Latency does not grow to extraordinary levels in cases of temporary link loss (TCP keeps doubling timeouts and can over-sleep substantially after a network issue is resolved).

I don’t see this as any kind of alternative to TCP for general usage, but for a narrow set of network requirements it seems useful.

It is somewhat of a given that this is reliable and order-preserving and stream-based, despite being based on UDP.On 03/13/2011 05:19 AM, David Olofson wrote:

On Sunday 13 March 2011, at 12.09.32, Tim Angus wrote:

On Sun, 13 Mar 2011 20:04:36 +1100 john wrote:

Note that TCP/IP is basically a useless protocol, its very badly
designed.

This is the funniest thing I’ve read today.

+1 :smiley:

Still, it’s served me and my former employer and countless others well for
ages - but then again, where do you draw the line between working with and
working around an API…?


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

This discussion is OT. The merits of TCP vs UDP is sort of like the merits
of running shoes vs boots. Each has a function and place. Now, back the the
original question.

Deepak,

I mean this is the best way possible, but you sound inexperienced and
probably should read more about how well-architectured network solutions are
designed and implemented. If you don’t know the merits of TCP vs UDP, you
need to stop writing code and read about their different properties. It also
looks like you need to understand the difference between polling and event
driven I/O. The high CPU usage from repeatedly calling a function is a loop
is the exact symptom of polling that many system calls have been created to
solve.On Sun, Mar 13, 2011 at 4:52 AM, deepak aggarwal <deepak.aggarwal9 at gmail.com wrote:

Wish they will make it more robust in near future.
But can you help me to find fix for it, might be assembly code which will
put thread in waiting queue(I/O) .
On 13-Mar-2011 2:34 PM, “john skaller” wrote:

On 13/03/2011, at 7:01 AM, deepak aggarwal wrote:

Hi John
You are write that we need some function that put a thread in IO queue
and keep in waiting state till it get input but still there is no function
provided

in SDL library

That’s why you need a real networking library. Libs like ZeroMQ are
likely
to be more cross platform and more robust than anything SDL has to offer.

This isn’t a criticism of the SDL authors: cross platform high
performance
"actually working" networking code is quite hard, so SDL just provides
some
basic stuff.

Note that TCP/IP is basically a useless protocol, its very badly
designed.
You really NEED something like ZeroMQ to add a message passing layer
properly.


john skaller
skaller at users.sourceforge.net


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

My original quesmtion is not about UDP or TCP . My question is about how we
can force a thread to get ijto i/o queue. As no function present in sdl_net
library provide this facility.

This discussion is OT. The merits of TCP vs UDP is sort of like the merits
of running shoes vs boots. Each has a function and place. Now, back the
the
original question.

Deepak,

I mean this is the best way possible, but you sound inexperienced and
probably should read more about how well-architectured network solutions
are
designed and implemented. If you don’t know the merits of TCP vs UDP, you
need to stop writing code and read about their different properties. It
also
looks like you need to understand the difference between polling and event
driven I/O. The high CPU usage from repeatedly calling a function is a
loop
is the exact symptom of polling that many system calls have been created
to
solve.

Wish they will make it more robust in near future.
But can you help me to find fix for it, might be assembly code which will
put thread in waiting queue(I/O) .

Hi John
You are write that we need some function that put a thread in IO queue
and keep in waiting state till it get input but still there is no
function

provided

in SDL library

That’s why you need a real networking library. Libs like ZeroMQ are
likely
to be more cross platform and more robust than anything SDL has to
offer.On 13-Mar-2011 11:00 PM, “Patrick Baggett” <baggett.patrick at gmail.com> wrote:
On Sun, Mar 13, 2011 at 4:52 AM, deepak aggarwal < @deepak_aggarwal wrote:

On 13-Mar-2011 2:34 PM, “john skaller” wrote:

On 13/03/2011, at 7:01 AM, deepak aggarwal wrote:

This isn’t a criticism of the SDL authors: cross platform high
performance
"actually working" networking code is quite hard, so SDL just provides
some
basic stuff.

Note that TCP/IP is basically a useless protocol, its very badly
designed.
You really NEED something like ZeroMQ to add a message passing layer
properly.


john skaller
skaller at users.sourceforge.net


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

My original quesmtion is not about UDP or TCP . My question is about how we
can force a thread to get ijto i/o queue. As no function present in sdl_net
library provide this facility.

Okay, let me rephrase. What you are saying makes no sense. What 'I/O Queue’
are you talking about? Why are you trying to force a thread into it/one?
You’re too busy trying to find a solution to the small picture “How do I
force a thread into an I/O queue” but you haven’t really defined the problem
you are trying to solve in the big picture. I bet that if you can describe
the overall goal of your program, someone will be able to help you with a
solution.On Sun, Mar 13, 2011 at 12:39 PM, deepak aggarwal < deepak.aggarwal9 at gmail.com> wrote:

See the first message of this thread. Then you are able to understand what
is my problem

My original quesmtion is not about UDP or TCP . My question is about how
we

can force a thread to get ijto i/o queue. As no function present in
sdl_net

library provide this facility.

Okay, let me rephrase. What you are saying makes no sense. What 'I/O
Queue’
are you talking about? Why are you trying to force a thread into it/one?
You’re too busy trying to find a solution to the small picture “How do I
force a thread into an I/O queue” but you haven’t really defined the
problemOn 13-Mar-2011 11:28 PM, “Patrick Baggett” <baggett.patrick at gmail.com> wrote:
On Sun, Mar 13, 2011 at 12:39 PM, deepak aggarwal < @deepak_aggarwal> wrote:
you are trying to solve in the big picture. I bet that if you can describe
the overall goal of your program, someone will be able to help you with a
solution.

See the first message of this thread. Then you are able to understand what
is my problem

I get that you are having high CPU usage in one small 10-20 line fragment.
Great, but what is your program supposed to be doing? Why have you chosen to
structure your program like that? etc. These are the details that would
help. Since you haven’t given any information like that, all I can do is say
is that you can reduce CPU usage by having OS wake up a thread only when a
socket has information. Maybe try SDLNet_AllocSocketSet() and related
functions. These functions ARE NOT replacements for a well designed program,
which is why I suggested you read up on the designs of different networked
programs before you go too much further in yours. Hint: if you’re polling
like this, it is probably a suboptimal one.

PatrickOn Sun, Mar 13, 2011 at 1:23 PM, deepak aggarwal <deepak.aggarwal9 at gmail.com wrote:

Hi am working on common libraries for setting up server and managing it. I
need this type of technique so that i can accept multiple request from
client and open socket for them on different threads i.e a concurrent server
thats why i have to use this type of technique.
One solution i find is to sleep this thread for some millisecond but this
method is suboptimal. Hope i shall find another way to solve this problem.

See the first message of this thread. Then you are able to understand
what

is my problem

I get that you are having high CPU usage in one small 10-20 line fragment.
Great, but what is your program supposed to be doing? Why have you chosen
to
structure your program like that? etc. These are the details that would
help. Since you haven’t given any information like that, all I can do is
say
is that you can reduce CPU usage by having OS wake up a thread only when a
socket has information. Maybe try SDLNet_AllocSocketSet() and related
functions. These functions ARE NOT replacements for a well designed
program,On 14-Mar-2011 12:11 AM, “Patrick Baggett” <baggett.patrick at gmail.com> wrote:
On Sun, Mar 13, 2011 at 1:23 PM, deepak aggarwal < @deepak_aggarwal wrote:
which is why I suggested you read up on the designs of different networked
programs before you go too much further in yours. Hint: if you’re polling
like this, it is probably a suboptimal one.

Patrick