in reply to AnyEvent code blocking Twiggy event loop

AE/Twiggi do not introduce any "magic": if your code is blocking and long-running, they "hang", just because that code is running. (Well, that's why there is workers: while one is blocked, some other could serve other clients meanwhile).

Now, to your problem with executing external programs: try to execute it via AnyEvent::Util::fork_call, which executes program asynchronously without blocking main execution thread. Then in forked child you can use backticks to get the result, transform it, and return to main execution process (worker).

WBR, basiliscos.
  • Comment on Re: AnyEvent code blocking Twiggy event loop

Replies are listed 'Best First'.
Re^2: AnyEvent code blocking Twiggy event loop
by Anonymous Monk on Apr 27, 2015 at 20:18 UTC
    I stumbled on to AnyEvent::Util::fork_call yesterday and it seems to work, but I'm still not understanding why AE::timer is blocking my main thread. My guess is that I'm interfering with another event loop, probably whatever one Twiggy uses to handle incoming requests. Also, is there any reason why code in timer or fork_call doesn't (seem to) execute at all under any other server (Starman, Gazelle, HTTP::Server::Simple, etc.)? Just a little something I noticed trying to piece together how this all works yesterday.
[reply]

      Timer by itself blocks nothing, while sleep could do that; Although I think AE should prevent that as bad practice. To return/simulate delayed response, try 

      use AE;

my $app =  sub {
    return sub {
        my $r = shift;
        my $t; $t = AE::timer 60, 0, sub {
            my $writer = $r->([200, ['Content-Type' => 'text/plain'] ]
+);
            $writer->write('Hello World');
            $writer->close;
            undef $t;
        };
    };
};

      [download]

      Also, please note, that not all servers are AE-compatible, i.e. they could use own loop mechanism, and there will be a problem with AE; e.g. starman.

      Another source of problem with fork: do not ever use any loop-related code in child (directly or indirectly), i.e. do system/exec ASAP.

      WBR, basiliscos.
[reply]
[d/l]

      but I'm still not understanding why AE::timer is blocking my main thread.

      Its not AE::time, its the blocking system calls sleep/ipc/qx

      AE is cooperative multitasking meaning if any one part of the code decides to block, no other piece of code gets a chance to run

      Also, is there any reason why code in timer or fork_call doesn't (seem to) execute at all under any other server (Starman, Gazelle, HTTP::Server::Simple, etc.)?

      maybe you're trying stuff on win32 ... impossible to guess at reasons without code/diagnostics

[reply]

In Section Seekers of Perl Wisdom