Re^2: Splitting one large timeout into few smaller ones..

Do you think there's some simple way of translating this:

 Event->idle(min=>$mint,max=>$maxt,
 cb=> [$sth,"method"],
 max_cb_tm=>$timeout,);
[download]

into POE? Or would I have to scrap all the code I have written so far and start from the beggining?

Also, the problem is not exactly with processes being slow, but with multiplying timeouts. Look:

sub vicous {
#....
  for (0..int(rand(1000))) {
    sleep(int(rand(10)));# this takes at most 10s  
 };
#...
}
[download]

All this code is wrapped in single timeout, ie

 alarm(10000);
 vicious();
 alarm(0);
[download]

Above written as example, not actual code, because as I said, I'm using Event and not the actual alarms, but, what I'm trying to do is:

sub vicious {
#...
  for (0..int(rand(1000))) {
     sleep(int(rand(10)));
#....
     alarm(0);#reset alarm, we're OK
     alarm(10);#reset alarm..
  }; 

#...
alarm(10);
vicious();
alarm(0);
[download]

This theoretically would result in every 'task' operation being kept under 10s.

Comment on Re^2: Splitting one large timeout into few smaller ones.. Select or Download Code

Replies are listed 'Best First'.
Re^3: Splitting one large timeout into few smaller ones.. by tall_man (Parson) on Apr 07, 2005 at 17:15 UTC
One thing you should know about POE is that it uses cooperative multitasking. Your example with "sleep" would not work as you wanted under POE without some changes. As it says here: As noted above, a POE application is a single-threaded process that pretends to perform asynchronous actions through a technique called cooperative multitasking. At any given time, only one subroutine inside a POE application is executing. If that one subroutine has a sleep 60; inside of it, the entire application will sleep for 60 seconds. No alarms will be triggered; no actions will occur. Smaller blocks of code mean that POE gets a chance to do other actions like cleaning up sessions that are shutting down or executing another event. That's why I suggested POE could manage your tasks if each was in a child process. It may be more trouble to adapt to POE than it's worth to you in this particular case, but if you were going to adopt Roy Johnson's forking idea, it would simplify the process management and communication.	[reply]

Replies are listed 'Best First'.

Re^3: Splitting one large timeout into few smaller ones..
by tall_man (Parson) on Apr 07, 2005 at 17:15 UTC

here

As noted above, a POE application is a single-threaded process that pretends to perform asynchronous actions through a technique called cooperative multitasking. At any given time, only one subroutine inside a POE application is executing. If that one subroutine has a sleep 60; inside of it, the entire application will sleep for 60 seconds. No alarms will be triggered; no actions will occur. Smaller blocks of code mean that POE gets a chance to do other actions like cleaning up sessions that are shutting down or executing another event.

That's why I suggested POE could manage your tasks if each was in a child process. It may be more trouble to adapt to POE than it's worth to you in this particular case, but if you were going to adopt Roy Johnson's forking idea, it would simplify the process management and communication.

[reply]