when I use detach() - I get a DBI error, so when I used join() I dont get the same.

In theory, they should ultimately be much of a muchness once the join has been called. The nice thing about detach is that the cleanup occurs immediately the thread ends rather than waiting until you get around to calling join. Which might save some memory overall if you are starting new threads on the fly as their stack segments can be reused (earlier).

when I use detach() - I get a DBI error, so when I used join() I dont get the same.

That suggests that you, or the modules you are using, have some kind of error, and warrants further investigation.

Thank you! But since both does the same cleanup and join() does it at a later stage - I think both should have the same memory efficiency !?!

But since both does the same cleanup and join() does it at a later stage - I think both should have the same memory efficiency

If you do:

my $a = async {
    ...
};
... some other stuff;

my $b = async {
    ...
};
$_->join for $a, $b;
[download]

Your peak memory usage may be slightly higher than if you do:

async {
    ...
}->detach;
... some other stuff;

async {
    ...
}->detach;
[download]

Because the second thread will require the process to allocate more virtual memory to accomodate the stack space for the second thread, because the first thread hasn't been joined when it is created.

Whereas, with the second snippet, the first thread may have completed before the second thread is created, and so the memory used by the first thread can be reused for the second. Thereby the total memory consumption may be a little lower. It's all a matter of timing.

If total memory consumption isn't a problem, just ignore it.

I'd still want to investigate the DBI error though. It is likely also a timing problem.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

If “memory efficiency” is what you are looking for, then ... don’t spawn large numbers of threads only to let them immediately die off.   (What I call the “flaming-arrow algorithm.”)

Start a small pool of threads and let them be persistent.   Let them service a queue into which you put work-requests, and let them either stick around forever or service some (large) number of requests before they terminate themselves.   (You might do that if you are worried about memory leaks.   Apache does this, for instance.)

Another good notion is to let threads handle not only the processing of requests, but their inflows and outflows as well.   In this scenario, the parent thread mostly spends its time “reaping” dead children, and generally watching over things to make sure that the proper number of child threads exist, that none of them appear to be hung (or hung-over?) and so on.   (And, well, sleeping most of the time.)

This arrangement is very “friendly” to the operating system, and this is where you will get the most real efficiency, both in terms of memory and in other things.

(P.S.:   There are many CPAN modules out there that can save you a lot of work in setting up arrangements like this.   “Do not do a thing already done.”)

You're at it again.

There are many CPAN modules out there that can save you a lot of work in setting up arrangements like this. “Do not do a thing already done.”)

No. There aren't. And the few that are there are mostly rubbish.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.