DBI is generally not CPU bound on the client side. Again, it's a case
where the client spends its time waiting idly, so this may be made non-
blocking. A number of components have been written to help you
execute DBI requests in the background.
A simple user lookup (presumably to authenticate a user) may take on
the order of a few hundredths of a second, possibly longer if the
table is large and poorly indexed, you mistakenly prepare() the select
statement each time, or your mysqld or network are saturated. None of
these problems are insurmountable:
Upgrade your mysqld.
Upgrade your network.
Properly index your table.
Shard your database.
....
You seem to be seeking examples where POE isn't necessarily
appropriate. I recommend looking for CPU-bound problems, since that's
where POE doesn't directly help. Even in the CPU-bound case, a
subthread or child process can externalize and parallelize the work.
POE can continue doing non-blocking work in the meantime, and it can
be notified when the side thread or process is done.
--
Rocco Caputo - rcap...@pobox.com
On May 2, 2009, at 03:03, Roy M. wrote:
Hi.
On Sat, May 2, 2009 at 2:56 PM, Rocco Caputo <rcap...@pobox.com>
wrote:
Incorrect. A lot of the work of transferring a file is waiting for
the data
to arrive. POE can wait for data to arrive in parallel without
threading.
POE::Component::Client::FTP may or may not be programmed to allow
this, but
POE can do it. It's a common misunderstanding to say "POE" when
you mean "a
module using POE". POE's authors have little control over how it's
used.
What if I have some blocking operation within a callback, e.g. MySQL
query in `authenticated` method in POE::Component::Client::FTP ?
I think unless I make it run as parellel, the bottomneck still exist
as it is single threaded?
Thanks.
