Here's an example from the Mojolicious Cookbook:

use Mojo::UserAgent;
use Mojo::IOLoop;

# Parallel non-blocking requests
my $ua = Mojo::UserAgent->new;

$ua->get('http://metacpan.org/search?q=mojo' => sub {
  my ($ua, $mojo) = @_;
  ...
});

$ua->get('http://metacpan.org/search?q=mango' => sub {
  my ($ua, $mango) = @_;
  ...
});

# Start event loop if necessary
Mojo::IOLoop->start unless Mojo::IOLoop->is_running;
[download]

So in this example there are two GET requests sent, and callbacks execute once the requests are fulfilled. The event loop is implemented by Mojolicious's standalone event loop, but if you have EV installed on your system, internally that will be used automatically, for improved performance.

Non-blocking concurrency seems to be a strong focus in Mojolicious's ongoing development. As a UserAgent, it's probably hard to find a solution that has better non-blocking IO support from its developers.

both threads ... with lwp useragent. But I have been facing 'out of memory' issues lately

That almost certainly means you've failed to control the level of concurrency, and/or not discovered/used the threads stacksize => nnnn runtime option. Post your threaded code and we can probably fix that for you.

However, the most memory efficient and fastest mechanism for performing parallel downloads that I've used is LWP::Parallel.

It's not the simplest -- that'd be a thread-pool -- but, used with care and understanding it can easily saturate most broadband connections whilst requiring almost no CPU and very small amounts of memory, and is far simpler than all of the other state-driven modules.

"Out of Memory" is likely more a symptom of a memory leak than of a coding implementation. There are differences between the different approaches to threading, but fundamentally they're doing pretty similar things. I'd suggest you're more likely to be suffering 'out of memory' as a result of something spawning new instances too aggressively.

Posting code might mean someone can point out the problem.