comment on

I like to know the pros and cons of possible solutions.

Threads are built-in, simple, portable and are working for you now.

The rest are non-portable add-ons, with huge learning curves, that produce complicated, hard to maintain code.

And they don't have a solution to fundamentally blocking apis like DBI.

Your question might make some sense if you had specific problems with the threaded solution, but it seems you are allowing the validity of your working code to be questioned on the basis of its 'coolness' with a particular group of people, who "don't like threads" but can't explain why. That's not good reasoning.

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.

In reply to Re: threads and their alternatives by BrowserUk
in thread Alternatives to threads for maintaining GUI app responsiveness by metaperl

Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
Want more info? How to link or How to display code and escape characters are good places to start.


Your skill will accomplish what the force of many cannot
	PerlMonks