[ViewVC] Diff of: cvs/Coro-Mysql/Mysql.pm

Comparing Coro-Mysql/Mysql.pm (file contents):
Revision 1.8 by root, Thu Jan 13 12:08:56 2011 UTC vs.
Revision 1.23 by root, Mon Mar 4 05:44:43 2019 UTC

 =head1 NAME
-Coro::Mysql - let other threads run while doing mysql requests
+Coro::Mysql - let other threads run while doing mysql/mariadb requests
 =head1 SYNOPSIS
  use Coro::Mysql;
 (Note that in this manual, "thread" refers to real threads as implemented
 by the Coro module, not to the built-in windows process emulation which
 unfortunately is also called "threads")
-This module "patches" DBD::mysql database handles so that they do not
+This module replaces the I/O handlers for a database connection, with the
-block the whole process, but only the thread that they are used in.
+effect that "patched" database handles no longer block the all threads of
+a process, but only the thread that does the request.
 This can be used to make parallel sql requests using Coro, or to do other
-stuff while mysql is rumbling in the background.
+stuff while mariadb is rumbling in the background.
 =head2 CAVEAT
 Note that this module must be linked against exactly the same (shared,
-possibly not working with all OSes) F<libmysqlclient> library as
+possibly not working with all OSes) F<libmariadb>/F<libmysqlclient>
-DBD::mysql, otherwise it will not work.
+library as L<DBD::mysql>, otherwise it will not work.
 Also, while this module makes database handles non-blocking, you still
 cannot run multiple requests in parallel on the same database handle. If
 you want to run multiple queries in parallel, you have to create multiple
-database connections, one for each thread that runs queries. Not doing so
+database connections, one for each thread that runs queries. Not doing
-can corrupt your data - use a Coro::Semaphore when in doubt.
+so can corrupt your data - use a Coro::Semaphore to protetc access to a
+shared database handle when in doubt.
 If you make sure that you never run two or more requests in parallel, you
 can freely share the database handles between threads, of course.
-Also, this module uses a number of "unclean" techniques (patching an
-internal libmysql structure for one thing) and was hacked within a few
-hours on a long flight to Malaysia.
-It does, however, check whether it indeed got the structure layout
-correct, so you should expect perl exceptions or early crashes as opposed
-to data corruption when something goes wrong during patching.
 =head2 SPEED
 This module is implemented in XS, and as long as mysqld replies quickly
 enough, it adds no overhead to the standard libmysql communication
-routines (which are very badly written, btw.).
+routines (which are very badly written, btw.). In fact, since it has a
+more efficient buffering and allows requests to run in parallel, it often
+decreases the actual time to run many queries considerably.
 For very fast queries ("select 0"), this module can add noticable overhead
-(around 15%) as it tries to switch to other coroutines when mysqld doesn't
+(around 15%, 7% when EV can be used) as it tries to switch to other
-deliver the data instantly.
+coroutines when mysqld doesn't deliver the data immediately, although,
+again, when running queries in parallel, they will usually execute faster.
 For most types of queries, there will be no extra latency, especially on
 multicore systems where your perl process can do other things while mysqld
 does its stuff.
 This module only supports "standard" mysql connection handles - this
 means unix domain or TCP sockets, and excludes SSL/TLS connections, named
 pipes (windows) and shared memory (also windows). No support for these
 connection types is planned, either.
+=head1 CANCELLATION
+Cancelling a thread that is within a mysql query will likely make the
+handle unusable. As far as Coro::Mysql is concerned, the handle can be
+safely destroyed, but it's not clear how mysql itself will react to a
+cancellation.
 =head1 FUNCTIONS
 Coro::Mysql offers a single user-accessible function:
 =over 4
 use Scalar::Util ();
 use Carp qw(croak);
 use Guard;
+use AnyEvent ();
-use Coro::Handle ();
+use Coro ();
+use Coro::AnyEvent (); # not necessary with newer Coro versions
 # we need this extra indirection, as Coro doesn't support
 # calling SLF-like functions via call_sv.
 sub readable { &Coro::Handle::FH::readable }
 sub writable { &Coro::Handle::FH::writable }
 BEGIN {
-   our $VERSION = '1.02';
+   our $VERSION = '2.0';
    require XSLoader;
    XSLoader::load Coro::Mysql::, $VERSION;
 }
 It is safe to call this function on any database handle (or just about any
 value), but it will only do anything to L<DBD::mysql> handles, others are
 returned unchanged. That means it is harmless when applied to database
 handles of other databases.
+It is also safe to pass C<undef>, so code like this is works as expected:
+   my $dbh = DBI->connect ($database, $user, $pass)->Coro::Mysql::unblock
+      or die $DBI::errstr;
 =cut
 sub unblock {
    my ($DBH) = @_;
-   if ($DBH->{Driver}{Name} eq "mysql") {
+   if ($DBH && $DBH->{Driver}{Name} eq "mysql") {
       my $sock = $DBH->{sock};
       open my $fh, "+>&" . $DBH->{sockfd}
          or croak "Coro::Mysql unable to clone mysql fd";
+      if (AnyEvent::detect ne "AnyEvent::Impl::EV" || !_use_ev) {
+         require Coro::Handle;
-      $fh = Coro::Handle::unblock $fh;
+         $fh = Coro::Handle::unblock ($fh);
+      }
-      _patch $sock, $DBH->{sockfd}, $fh, tied ${$fh};
+      _patch $sock, $DBH->{sockfd}, $DBH->{mysql_clientversion}, $fh, tied *$$fh;
    }
    $DBH
 }
    use PApp::SQL;
    sub with_db($$$&) {
       my ($database, $user, $pass, $cb) = @_;
-      my $dbh = Coro::Mysql::unblock DBI->connect ($database, $user, $pass)
+      my $dbh = DBI->connect ($database, $user, $pass)->Coro::Mysql::unblock
          or die $DBI::errstr;
       Coro::on_enter { $PApp::SQL::DBH = $dbh };
       $cb->();
    }
 This function makes it possible to easily use L<PApp::SQL> with
 L<Coro::Mysql>, without worrying about database handles.
    # now start 10 threads doing stuff
 =head1 SEE ALSO
 L<Coro>, L<PApp::SQL> (a user friendly but efficient wrapper around DBI).
+=head1 HISTORY
+This module was initially hacked together within a few hours on a long
+flight to Malaysia, and seems to have worked ever since, with minor
+adjustments for newer libmysqlclient libraries.
+Well, at least until mariadb introduced the new Pluggable Virtual IO API
+in mariadb 10.3, which changed and broke everything. On the positive
+side, the old system was horrible to use, as many GNU/Linux distributions
+forgot to include the required heaqder files and there were frequent small
+changes, while the new PVIO system seems to be "official" and hopefully
+better supported.
 =head1 AUTHOR
  Marc Lehmann <schmorp@schmorp.de>
  http://home.schmorp.de/

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing Coro-Mysql/Mysql.pm (file contents): Revision 1.8 by root, Thu Jan 13 12:08:56 2011 UTC vs. Revision 1.23 by root, Mon Mar 4 05:44:43 2019 UTC

Diff Legend

Comparing Coro-Mysql/Mysql.pm (file contents):
Revision 1.8 by root, Thu Jan 13 12:08:56 2011 UTC vs.
Revision 1.23 by root, Mon Mar 4 05:44:43 2019 UTC