methaneのブログ

このブログに乗せているサンプルコードはすべてNYSLです。

MySQL Connector/C の代わりに MariaDB Connector/C を使う

mysqlclientWindows 版バイナリ wheel を作るために、以前は MySQL Connector/C を使っていたのですが、しばらく問題があって利用できませんでした。

  • static link library が提供されない
  • ビルドの仕方がよくわからん。ドキュメントもない。
  • TLS と sha256_password / caching_sha2_password のために OpenSSL がいる

ちなみに、 MySQL Connector/PythonWindows 版は site-packages 直下 (つまりグローバル) に OpenSSL の dll を含めて必要なものを全部ぶちまけるようになっています。ロックだ。それと同じロックな手段をとると当然衝突します。

そこで MariaDB Connector/C の動向をウォッチしていたのですが、最近色々な条件が揃ったので、 mysqlclient の Windows 版は MariaDB Connector/C を使うようにしました。

  • static link をサポートしている
  • ビルドの仕方が(一応)ドキュメントされてる
  • TLS も sha256_password や caching_sha2_password も OpenSSL ではなく Windows API を利用しているので OpenSSL の同梱が不要。

MariaDB Connector/C は Windows 版バイナリを配布しているのですが、 caching_sha2_password などのプラグインが DLL の状態で同梱されているので、完全 static link したい場合にはちょっとあいません。

wiki に完全 static なライブラリのビルド方法を残しておいたので、必要な方は参考にしてください。

go-sql-driver/mysql の QueryContext でコンテキストをキャンセルしたら race が起こる

タイトルの通り、 QueryContext の第一引数に渡した Context を、 Rows.Close() を呼び出す前にキャンセルすると、 race が起こる可能性があります。

修正する pull request を作成したのですが、メンテナが作ったプルリクエストは他のメンテナのレビューなしにマージしてはいけないというルールがあるのでまだマージしていません。なので、 QueryContext を利用するときは注意してください。

github.com

問題になるコード

Rows.Scan() の引数の型が *[]byte だった場合、受け取った []byte の中身が他の goroutine から書き換えられることがあります。

rows, err := db.QueryContext(ctx, "select ...", ...)
if err != nil {
    // ...
}
defer rows.Close()

for rows.Next() {
    var []buf
    err := rows.Scan(&buf)
    fmt.Println(buf) // buf の中身が他の goroutine から書き換えられる
}

また引数の型が *interface{} だった場合にも、その interface{}[]byte が格納され、その中身が他の goroutine から書き換えられることがあります。

背景

database/sql の設計は、 driver の API は1つの接続だけを扱う(コネクションプール部分は全て database/sql が解決する)、そしてその1つの接続に対して並行で driver の API が呼ばれることはない、ようになっています。

また、 rows.Scan()[]byte を出力する場合、その参照先の部分は次の rows.Next()rows.Close() 以降はドライバが再利用できるようになっています。これは受信バッファの中身を直接スライスで返すことで余分なアロケートとコピーを減らすためです。

コンテキスト対応が入るまではこれでうまくいっていました。しかし、 database/sql がコンテキストに対応する時に、コンテキストのキャンセルを別 goroutine で監視して、アプリケーションからの rows.Close()rows.Scan() を待たずにドライバー側の rows.Close() を呼び出すようにしてしまったのです。

Go 1.10 の changelog

結果として次のような状況になりました。

  • rows.Scan() が返した []byte 受信バッファの中を直接参照しています。アプリケーションは次の rows.Next()rows.Close() を呼び出すまではその中身を合法的に読むことができます。
  • ドライバは rows.Close()rows.Next() が呼ばれた場合、前回の Scan() で返した []byte の中身を破壊していいので、送受信バッファとして再利用します。
  • database/sql はコンテキストがキャンセルされると別 goroutine からドライバ側の rows.Close() を呼び出します。

正直、なんてことしてくれたんだ!って感じです。アプリケーションが rows.Next() を呼ぶまで待ってくれたらいいのに。なんでわざわざ別 goroutine で。。。

たぶん一刻も早くキャンセルしたかったんでしょうが、MySQLでは百害あって一理ありません。 MySQL でクエリのキャンセルは難しいのでまだ実装してないし、たとえ実装していたとしても、 rows.Next() が一回でも呼ばれているということはクエリの実行はすでに終わっています。 rows.Next() を待たずにキャンセルするメリットが現在も将来も一切ありません。

Sony の SBH90C レビュー

https://www.amazon.co.jp/dp/B07CZQMYKK/ref=as_li_ss_tl?&hvadid=274798673996&hvpos=1o3&hvnetw=g&hvrand=13734372561970267267&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1028853&hvtargid=pla-465703230864&th=1&psc=1&linkCode=ll1&tag=py0d-22&linkId=9446964464023e4d4ba0cec75ac27735&language=ja_JP

それまでは Anker の Zolo Liberty を使っていたけれども、遅延が激しくてアニメ鑑賞でも気になっていたので買い替えた。 Zolo Liberty は codec が AAC なうえに、完全ワイヤレスだから左右間の再転送も必要で遅くなっているんだと思う。2019年のTWS Plus と apt-x Adaptive に期待している。

SBH90C は apt-x に対応しているのと、ネックバンド型だから左右転送の遅延もなく、きっと無線も安定しているだろうというのでチョイス。 Type-C ケーブルでデジタル接続に対応しているのもオタク心を刺激する。

感想&気になった点。

  • 専用のType-C ケーブルの太さはまだ良いが、しなやかさがイヤホンケーブルとしてはちょっと。。。ケーブルを柔らかくできないなら有線はアナログのほうが良かったと思う。
  • 有線時の遅延はスクフェスプレイに問題が無いレベル。
  • イヤホンジャック利用時はスマホの横画面でどちらを上にしたほうがスクフェスプレイがやりやすいかがデフォルトの横画面の向きと逆で、「回転」をOn/Offする必要があった。 Type-C ジャックは中央にあるので画面表示に合わせてスマホを持てて楽。
  • 無線の安定性は驚くほど上がった。中目黒駅での乗り換えで Liberty は壊滅状態だったが、 SBH90C は無問題。
  • 無線の遅延も動画視聴してる限りは気にならない。(音ゲーは最初から期待してないので試してないが、それ以外のゲームなら多分問題ない)
  • カナル型なのに、遮音性が驚くほど低い。「ポート」と呼ばれる穴があるせい。ノイズキャンセリングも無いので、通勤用途には厳しかった。セロテープかなにかでポートを塞いで見るつもり。
  • torne mobile が USB 接続だとエラーになる!スクフェス後にそのままアニメ見たいときや、充電したいときに困る。大人の事情だとは思うけどこういうつまらない制限でユーザビリティを下げるのはやめてほしい。

結論: 通勤用途には WI-1000X (と Type-C → アナログ変換ケーブル) のほうが向いてそう。

MySQL Connector/C の現状

MySQL 8 が GA になってたときは MySQL がどういうつもりなのかいまいち分からなかったのですが、 8.0.13 リリースを機に改めて調べてみたらこんな感じでした。

  • 従来の MySQL Connector/C は単体提供されない。サーバーをインストールしたらついてくる。
  • MySQL Connector/C++ は、client/server protocol の方のAPIC++ しか対応していない。 X Dev API の方は C 言語でも利用可能な形式になっている。

MySQL :: Download Connector/C (libmysqlclient)

ところで、Windows 版クライアントを考えたときに面白いのが MariaDB Connector/C です。 MySQL Connecotr/C が Windows 版でも OpenSSL 同梱になった等、 static link でシングルバイナリを作る使い方がほぼ不可能になったのに対して、 MariaDB Connector/C は OpenSSL を使わずに WindowsAPI を使って sha256_password や SSL 接続に対応していて、開発版では caching_sha2_password にも対応しました。

MySQL Connector/C がどうなってるのか公式のアナウンスがなかったのと、 MySQL Connector/Python が site-packages 直下に OpenSSL とか MySQL client の DLL とかをブッ込んでくる強硬手段を取ってきたので同じことをするとコンフリクトするので、 mysqlclient-pythonWindows版の wheel の提供を中断していました。

MariaDB Connector/C であれば static link で DLL ブッコミ不要の従来どおりの提供ができそうなので、 caching_sha2_password 対応版が出たらそっちに切り替えるつもりでいます。

Python の repr(float) を高速化する

Python の repr(float) は、 float(repr(float)) が保証される最短の表現を返します。 実装には netlib の dtoa を使っています。

この dtoa より速い実装が世の中にはあって、 V8 なんかで使われているようです。

github.com

float の repr の実装をこの速いやつに入れ替えるパッケージが frepr です。 frepr.install()float.__repr__ を入れ替えてしまうので、 jsonエンコードなども速くすることができるらしい。

Python で float のデータを大量に扱う人には嬉しそう。