in reply to Re: I want to forfeit my timeshare
in thread I want to forfeit my timeshare

That's only if you use blocking, which is sometimes undesirable. How about if I want to check four sockets just once per slice?

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.

Replies are listed 'Best First'.
Re: Re: Re: I want to forfeit my timeshare
by John M. Dlugosz (Monsignor) on Aug 25, 2001 at 00:02 UTC
    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

[reply]
      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.

[reply]
        I think that "check once per time slice" should be "check every X seconds" where X is some specific value (e.g. 0.01) rather than whatever the quantum happens to be right now.

        In Win32, which I'm most familar with, the sleep primitive is naturally rounded off to the timeslice boundary. That's because it's between time slices that it updates the thread's ready status if the time expired since the last time it checked. I think that's such a natural way of implementing it that it would do this on any OS, more or less.

        So, sleep(0.0000001) would probably naturally give up the timeslice but stay on the ready list. In Win32, threads at the same priority are round-robin.

        If an OS rounds =down= and decides not to sleep at all, then a more carefully chosen value of X would still work! Look up the quantum length and use that. It will expire midway through the next slice, but will not be taken as 0.

        In general, sleep(qsize) will do exactly what you are asking for. sleep(very_small_value) probably does so, too.

        —John

[reply]

In Section Seekers of Perl Wisdom