coro::util(3pm) [debian man page]

Util(3pm)						User Contributed Perl Documentation						 Util(3pm)

NAME

       Coro::Util - various utility functions.

SYNOPSIS

	use Coro::Util;

DESCRIPTION

       This module implements various utility functions, mostly replacing perl functions by non-blocking counterparts.

       Many of these functions exist for the sole purpose of emulating existing interfaces, no matter how bad or limited they are (e.g. no IPv6
       support).

       This module is an AnyEvent user. Refer to the AnyEvent documentation to see how to integrate it into your own programs.

       $ipn = Coro::Util::inet_aton $hostname || $ip
	   Works almost exactly like its "Socket::inet_aton" counterpart, except that it does not block other coroutines.

	   Does not handle multihomed hosts or IPv6 - consider using "AnyEvent::Socket::resolve_sockaddr" with the Coro rouse functions instead.

       gethostbyname, gethostbyaddr
	   Work similarly to their Perl counterparts, but do not block. Uses "AnyEvent::Util::inet_aton" internally.

	   Does not handle multihomed hosts or IPv6 - consider using "AnyEvent::Socket::resolve_sockaddr" or "AnyEvent::DNS::reverse_lookup" with
	   the Coro rouse functions instead.

       @result = Coro::Util::fork_eval { ... }, @args
	   Executes the given code block or code reference with the given arguments in a separate process, returning the results. The return
	   values must be serialisable with Coro::Storable. It may, of course, block.

	   Note that using event handling in the sub is not usually a good idea as you will inherit a mixed set of watchers from the parent.

	   Exceptions will be correctly forwarded to the caller.

	   This function is useful for pushing cpu-intensive computations into a different process, for example to take advantage of multiple
	   CPU's. Its also useful if you want to simply run some blocking functions (such as "system()") and do not care about the overhead enough
	   to code your own pid watcher etc.

	   This function might keep a pool of processes in some future version, as fork can be rather slow in large processes.

	   You should also look at "AnyEvent::Util::fork_eval", which is newer and more compatible to totally broken Perl implementations such as
	   the one from ActiveState.

	   Example: execute some external program (convert image to rgba raw form) and add a long computation (extract the alpha channel) in a
	   separate process, making sure that never more then $NUMCPUS processes are being run.

	      my $cpulock = new Coro::Semaphore $NUMCPUS;

	      sub do_it {
		 my ($path) = @_;

		 my $guard = $cpulock->guard;

		 Coro::Util::fork_eval {
		    open my $fh, "convert -depth 8 Q$pathE rgba:"
		       or die "$path: $!";

		    local $/;
		    # make my eyes hurt
		    pack "C*", unpack "(xxxC)*", <$fh>
		 }
	      }

	      my $alphachannel = do_it "/tmp/img.png";

AUTHOR

	Marc Lehmann <schmorp@schmorp.de>
	http://home.schmorp.de/

perl v5.14.2							    2012-04-13								 Util(3pm)

LWP(3pm)						User Contributed Perl Documentation						  LWP(3pm)

NAME

       Coro::LWP - make LWP non-blocking - as much as possible

SYNOPSIS

	use Coro::LWP; # afterwards LWP should not block

ALTERNATIVES

       Over the years, a number of less-invasive alternatives have popped up, which you might find more acceptable than this rather invasive and
       fragile module. All of them only support HTTP (and sometimes HTTPS).

       AnyEvent::HTTP
	   Works fine without Coro. Requires using a very different API than LWP. Probably the best choice iff you can do with a completely
	   different event-based API.

       LWP::Protocol::AnyEvent::http
	   Makes LWP use AnyEvent::HTTP. Does not make LWP event-based, but allows Coro threads to schedule unimpeded through its AnyEvent
	   integration.

	   Let's you use the LWP API normally.

       LWP::Protocol::Coro::http
	   Basically the same as above, distinction unclear. :)

       AnyEvent::HTTP::LWP::UserAgent
	   A different user agent implementation, not completely transparent to users, requires Coro.

DESCRIPTION

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

       This module tries to make LWP non-blocking with respect to other coroutines as much as possible, and with whatever means it takes.

       LWP really tries very hard to be blocking (and relies on a lot of undocumented functionality in IO::Socket), so this module had to be very
       invasive and must be loaded very early to take the proper effect.

       Note that the module AnyEvent::HTTP might offer an alternative to the full LWP that is designed to be non-blocking.

       Here is what it currently does (future versions of LWP might require different tricks):

       It loads Coro::Select, overwriting the perl "select" builtin globally.
	   This is necessary because LWP calls select quite often for timeouts and who-knows-what.

	   Impact: everybody else uses this (slower) version of select, too. It should be quite compatible to perls builtin select, though.

       It overwrites Socket::inet_aton with Coro::Util::inet_aton.
	   This is necessary because LWP might (and does) try to resolve hostnames this way.

	   Impact: some code might not expect coroutine semantics, for example, when you fork you might prefer the blocking variant because other
	   coroutines shouldn't actually run.

       It replaces the base class of Net::HTTP, Net::FTP, Net::NNTP.
	   This is necessary because LWP does not always use select to see whether a filehandle can be read/written without blocking, so the base
	   class "IO::Socket::INET" needs to be replaced by "Coro::Socket".

	   Impact: Coro::Socket is not at all compatible to IO::Socket::INET. While it duplicates some undocumented functionality required by LWP,
	   it does not have all the methods of IO::Socket::INET and might act quite differently in practise. Also, protocols other than the above
	   mentioned will still block, at least some of the time.

       All this likely makes other libraries than just LWP not block, but thats just a side effect you cannot rely on.

       Increases parallelism is not supported by all libraries, some might cache data globally.

AUTHOR

	Marc Lehmann <schmorp@schmorp.de>
	http://home.schmorp.de/

perl v5.14.2							    2012-04-13								  LWP(3pm)