2009/11/30 Jay Savage <daggerqu...@gmail.com>:
> On Mon, Nov 30, 2009 at 1:42 PM, David Schmidt <zivildie...@gmail.com> wrote:
>> On Mon, Nov 30, 2009 at 5:57 PM, John W. Krahn <jwkr...@shaw.ca> wrote:
>>> David Schmidt wrote:
>
>>>> Yes my program has to continue while waiting for the timeout.
>>>> You code example doesn't work for me because my program is an entire
>>>> Catalyst application which I dont think is a good idea to put into an
>>>> eval block.
>>>
>>> You may not need an eval block:
>>>
>>> perldoc -f alarm
>>> [ SNIP ]
>>> If you want to use "alarm" to time out a system call you
>>> need to use an "eval"/"die" pair. You can’t rely on the
>>> alarm causing the system call to fail with $! set to "EINTR"
>>> because Perl sets up signal handlers to restart system calls
>>> on some systems. Using "eval"/"die" always works, modulo
>>> the caveats given in "Signals" in perlipc.
>>>
>>>
>>> And besides, an eval with a block is compiled at the same time as the rest
>>> of your program and doesn't have the run-time overhead of a string eval.
>>>
>>
>> So basically I could create my Signalhandler for the alarm signal, do
>> my calculations in the signalhandler and then start another alarm()?
>>
>> $SIG{ALRM} = {
>> # do stuff
>> alarm($timeout_2);
>> };
>> alarm $timeout_1;
>>
>> And in case this works, is it a good and stable way to solve my problem?
>
>
> Almost certainly not. *If* it works for you it is relying on some
> features specific to your specific operating system and version, and
> is not portable, and probably not reliable. Unless have written all
> the modules yourself (which is unlikely, as you said this is involves
> catalyst), you also don't know everything else that is going on in
> your scope. Make sure you read the alarm and perlipc perldocs before
> attempting something like this, and pay special attention to both your
> OS and Perl version. You *may* not need eval, but it is almost
> certainly a good idea. Think of eval {} / if $@ as Perl's approach to
> the try/catch idiom of some other languages. You might also want to
> take a look at Exception::Base.
>
> We're still not certain what your problem is, though. That makes it
> difficult to give you specific advice. The purpose of an alarm or
> timeout is normally to interrupt the flow of the program and take some
> action when the time is up or if something doesn't happen in the
> allotted time.
>
> What you seem to be doing is setting up two independent execution
> paths: none of your psuedocode indicates that the alarm breaks into
> the main routine or that the execution paths rejoin. If that is really
> the case, what you probably really need to do is just spawn a child
> process with fork() or IPC::Open3 or similar.
>
> In any case, a real working (or not working as the case may be)
> example would go a long way toward helping us help you.
>
Due to some other restrictions I had to look for a different solution
and found one, namely to check if the time has expired when I am
accessing the data that has to be changed. Anyways, I dont want to let
this mail unanswered.
The actual problem is:
All the visitors have to be put in one of 4 groups. So for the first
10 minutes visitors go to group #1, next 10 minutes to group #2,
...when all 4 groups have been treated I want to calculate the new
"online" times of each group by looking at how many visitors are in
each one. If a group has very few visitors it gets a bigger share of
the next 40 minutes and so on.
What I am looking for now is a way to trigger this recalculation code
after the first 40 minutes. (I am not alternating groups after each
visitor for another reason)
*** at program start
my $timeslices = {
1 => 10,
2 => 10,
3 => 10,
4 => 10,
};
*** after 40 minutes, group 1 had the fewest visitors
my $timeslices = {
1 => 5,
2 => 10,
3 => 10,
4 => 15,
};
...and so on
david
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
