Normally we'd do something like this:

while (1) {
foreach ( $s -> can_read) {
 recv $_, $buffer, 1000;
}
print ".";
}
[download]

but as a recent petitioner noted, the CPU use hits 95%. Of course that's because it's using up all the available idle time, and not actually cutting into another processes time, but it's still not neat. And there's no way to get away from that select statement.

____________________
Jeremy
I didn't believe in evil until I dated it.

For polling?! Use an explicit timer rather than the nebulus "once per slice". Especially if after giving up your slice (there's an undocumented way to do it in Win32) you are immediatly run again as being the highest priority thread waiting!

I think Perl 6 will allow decimal seconds in the sleep command, so you can say e.g. sleep(0.01);.

In Win32, I'd never write such a loop anyway. I have Winsock post a message when activity occurs (ready to read, ready to write, etc) on a socket, and that is handled along with the GUI messages.

So what you really want is a standard Perl syntax for having socket activity trigger a callback dispatch, and that mechanism can be implemented in whatever way is nice and efficient on each platform.

—John

I'm sorry that my initial example was so tenuous, but I didn't really have a pat example to post. I was thinking more of situations where you may or may not have to check a few sockets, update the GUI a bit (someone below mentions the Tk/Gtkevent loop, which is close to what I want) and do a few other tasks, not necessarily ones that you can setup callbacks for (check some conditions maybe).

I can see reasons for doing it such as a pop-up window killer. You would check once per time slice whether that window was there, and then get out if there weren't any windows with the offending name. Sleep would work, but it would be more elegant to swat the window the timeslice after it appeared, rather than a 10th of a second later.

In my case I'm writing a servent (gnutella client), and I see now that a better way to do it would be to process all the stuff I need to, then the last command in the internal loop should be a blocking select with a short timeout.

I am currently rewriting it as a forking servent but there are some very nice benefits to keeping it all in the same process (eg shared data structures). Under windows you would certainly thread it but perl threading support is (as I understand it) still in development.

I hadn't realised that windows would reschedule the process to have the highest priority.

____________________
Jeremy
I didn't believe in evil until I dated it.