view release on metacpan or  search on metacpan

Coro/LWP.pm  view on Meta::CPAN

Coro threads to schedule unimpeded through its AnyEvent integration.

Lets you use the LWP API normally.

=item L<LWP::Protocol::Coro::http>

Basically the same as above, distinction unclear. :)

=item L<AnyEvent::HTTP::LWP::UserAgent>

A different user agent implementation, not completely transparent to
users, requires Coro.

=back

=head1 DESCRIPTION

This module is an L<AnyEvent> user, you need to make sure that you use and
run a supported event loop.

This module tries to make L<LWP|LWP> non-blocking with respect to other

Coro/Socket.pm  view on Meta::CPAN

   # and call Coro::Handle::unblock on it.

   tcp_connect "www.google.com", 80, Coro::rouse_cb;
   my $fh = unblock +(Coro::rouse_wait)[0];

   # now we have a perfectly thread-safe socket handle in $fh
   print $fh "GET / HTTP/1.0\015\012\015\012";
   local $/;
   print <$fh>;

Using C<AnyEvent::Socket::tcp_connect> gives you transparent IPv6,
multi-homing, SRV-record etc. support.

For listening sockets, use C<AnyEvent::Socket::tcp_server>.

=over 4

=cut

package Coro::Socket;

Coro/State.pm  view on Meta::CPAN

However. this is not always possible: For example, when Perl calls a C/XS function
(such as an event loop), and C then invokes a Perl callback, reconfiguring
the interpreter is not enough. Coro::State detects these cases automatically, and
attaches a C-level thread to each such Coro::State object, for as long as necessary.

The C-level thread structure is called "C context" (or cctxt for short),
and can be quite big, which is why Coro::State only creates them as needed
and can run many Coro::State's on a single cctxt.

This is mostly transparent, so the following methods are rarely needed.

=over 4

=item $state->has_cctx

Returns whether the state currently uses a cctx/C context. An active
state always has a cctx, as well as the main program. Other states only
use a cctxts when needed.

=item Coro::State::force_cctx