Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^4: regarding 1.02 (was Re: IO::Lambda: call for participation)

by xdg (Monsignor)
on Jan 15, 2009 at 00:21 UTC ( #736424=note: print w/replies, xml ) Need Help??

in reply to Re^3: regarding 1.02 (was Re: IO::Lambda: call for participation)
in thread IO::Lambda: call for participation

So these are really "on_next_writable" and "on_next_readable" rather than general event handlers. (Unless they are reset with again().) That's definitely different from POE, in which event handlers persist once set.

So, conceptually, it's sort of like this (in a sort of pseudo-code and with some lexical scope differences so that the function references are explicit which I think makes the order of execution clearer):

my ($req, $socket, $buf); sub talk { $req = shift; $socket = IO::Socket::INET-> new( PeerAddr => '', PeerPo +rt => 80); return lambda \&init; } sub init { when_writeable( $socket, \&write_handler ); } sub write_handler { send_request( $req => $socket ); when_readable( $socket, \&read_handler ); } sub read_handler { read_stuff( $socket => $buf ) or die; if ( done() ) { return $buf; } else { when_readable( $socket, \&read_handler ); } } my $q = talk( HTTP::Request-> new( GET => '') ); print $q->wait;


Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^5: regarding 1.02 (was Re: IO::Lambda: call for participation)
by dk (Chaplain) on Jan 15, 2009 at 00:44 UTC
    That's definitely different from POE, in which event handlers persist once set.

    Quite correct. I didn't realize that this is a key point difference until you've noticed it - thank you! I agree, it surely is. I should emphasize that in the docs.

    And yes, the code does the right flow.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://736424]
[Corion]: marto: Yeah, feels like that ;) You could set up the cronjob that auto-creates tickets :-))
[marto]: the ticketing system does not accept calls via email, nor has it a working API. It's tied into Active Directory for authentication and the Solaris boxes aren't on that domain
[Corion]: The one thing I haven't figured out a solution to is how to get an edge-trigger instead of sending an email every 5 minutes if the usage is above 90%. I want one mail when it goes over 90% but no more emails as long as it stays between 90% and 95%.
[Corion]: marto: Clever! ;)
[Corion]: You can only reach me by pager
[Corion]: Maybe the solution would be to launch a cron job every minute that takes two measurements a minute apart and sends a mail if the usage is below on the first and above threshold on the last measurement
[marto]: that's essentially it :)
[marto]: I think the long term solution would be to have sysadmins that do their job, so I don't have to do everything :P
[marto]: they already have an entire BMC patrol system, which they disabled, because it was sending out spurious messages. So rather than fix the issue, or even find out what it was, they turned it off. No messages, can't be any problems, right?
[Corion]: marto: But having open tickets / incidents increases the pressure on them ;) Of course, likely your contract / SLA specifies an upper limit for the number of incidents :-D

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (7)
As of 2017-01-24 10:12 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (203 votes). Check out past polls.