Re^2: Issue with time() in loop?

Yes there is constantly data on the socket. I know this by printing it to screen when it comes through. Even if there was not it is a non blocking socket.

Maybe the example I gave was not a very good representation. It seems that most of the replys are focusing on the socket and the thread when these are more than likely not the issue. I am using threads because that is what my application calls for. IO::Select would not be the best choice in my case because there are thousands of lines of code a second coming across more than 100 socket connections simultaneously. I chose the method I did because of what my app does.

It was also suggested to use the timeout feature of IO::Select, this would also not be what I want becasue I want the function to be executed after a set amount of time no matter if the socket is receiving data or not. It was also asked if I know this is happening becasue I wait 25 minutes? Well actually no, I know it is happening because I wait two or three hours when it is suppose to happen after 30 minutes and it never does. I also use threads because in the real application I detach this thread so it monitors the time and only the time independant of anything else that is going on in the application.

I know not all of this applies to your post Tanktalus, but I just wanted to reply to everyones questions so far in one place. Maybe this will give a better idea of what is going on?

Edit: I also forgot to mention that my original question was a bit misleeding. The detached thread I use to check the time does use a simple while (1) loop. In the application for each thread I also use another while loop monitoring the socket. I kinda mixed those two together.

Comment on Re^2: Issue with time() in loop? Download Code

Replies are listed 'Best First'.
Re^3: Issue with time() in loop? by Tanktalus (Canon) on Nov 13, 2005 at 20:39 UTC
Then, I would suggest rethinking your design, if you can. e.g., I hear about POE, perhaps that would be a better way to design to make it easier to debug. Even without POE, you could do all this on a single thread using IO::Select. Especially if there's only one CPU anyway, having multiple threads isn't going to make your program go (much) faster. It will be a battle between the overhead of task switching in the kernel (far removed from your app) and the optimisation of that task switching. Otherwise, selecting on your hundred ports will probably be faster and easier to write. A distinct possibility in your current problem is that this thread is chewing up so much CPU time that the OS starts to throttle it, and outright ignore it. Try inserting a "sleep(1)" in your loop so that it only checks once per second, rather than as often as the CPU (and OS) allows. Or, better yet, calculate the time difference between now and the desired time, and sleep for that long - which will use zero CPU time until the desired time.	[reply]

Replies are listed 'Best First'.

Re^3: Issue with time() in loop?
by Tanktalus (Canon) on Nov 13, 2005 at 20:39 UTC

Then, I would suggest rethinking your design, if you can. e.g., I hear about POE, perhaps that would be a better way to design to make it easier to debug.

Even without POE, you could do all this on a single thread using IO::Select. Especially if there's only one CPU anyway, having multiple threads isn't going to make your program go (much) faster. It will be a battle between the overhead of task switching in the kernel (far removed from your app) and the optimisation of that task switching. Otherwise, selecting on your hundred ports will probably be faster and easier to write.

A distinct possibility in your current problem is that this thread is chewing up so much CPU time that the OS starts to throttle it, and outright ignore it. Try inserting a "sleep(1)" in your loop so that it only checks once per second, rather than as often as the CPU (and OS) allows. Or, better yet, calculate the time difference between now and the desired time, and sleep for that long - which will use zero CPU time until the desired time.

[reply]