Go1.8のpluginパッケージでGopherLuaに共有ライブラリロードを実装してみた

Go Advent Calendar 2016 16日目です。去年に引き続き今年も3つカレンダーがあり相変わらずの人気ですね。

さて、Go1.8では待望？のShared Libraryのロードが可能になります。 pluginパッケージ を使います。

Go1.8beta1ではLinuxとMacOSがサポートされていたのですが、MacOSで問題が見つかりbeta2ではLinuxのみで利用可能な機能となります。

Advent Calendar 2の qt-luigiさんのネタ と被ってしまったのですが実戦的に使ってみました、ということで許してください。

プラグインの作成とコンパイル

マニュアルページにあるとおり、以下のようになります。

 1package main
 2
 3// // No C code needed.
 4import "C"
 5
 6import "fmt"
 7
 8var V int
 9
10func F() { fmt.Printf("Hello, number %d\n", V) }

ポイントは

  • Cのコードはないが、 import "C" が必要
  • package は main

という２点です。コンパイルは

1$ go build -buildmode=plugin -o plugin.so plugin.go

でOK。簡単ですね。これで plugin.so が生成されます。

プラグインのロード

これまたマニュアルページどおりですが

 1p, err := plugin.Open("plugin.so")
 2if err != nil {
 3    panic(err)
 4}
 5v, err := p.Lookup("V")
 6if err != nil {
 7    panic(err)
 8}
 9f, err := p.Lookup("F")
10if err != nil {
11    panic(err)
12}
13*v.(*int) = 7
14f.(func())() // prints "Hello, number 7"

のように非常に直感的に使えます。

GopherLuaで使ってみた

拙作のPure GoによるLua実装 GopherLua ですが(何気にstarいっぱいでうれしいですね)、当然ながらC言語実装のように共有ライブラリをロードできませんでした。

そのため、必要なライブラリはすべて事前に組み込んでおく必要がありました。そこでGo1.8で共有ライブラリロードを実装できるのか、実装できるだろうけどちゃんと動くのか、と思い試してみました。

こちらは feature-exp-go1.8pluginsブランチ で実際に動かせます。プラグイン部分のコミットは 571b031 です。

まずプラグイン側から。Luaのお作法通りです。

 1package main
 2
 3import (
 4    "C"
 5    "github.com/yuin/gopher-lua"
 6)
 7
 8func Add(L *lua.LState) int {
 9    v1 := L.CheckInt(1)
10    v2 := L.CheckInt(2)
11    L.Push(lua.LNumber(v1 + v2))
12    return 1
13}
14
15func LuaOpenPlugin(L *lua.LState) int {
16    L.Push(
17        L.SetFuncs(L.NewTable(), map[string]lua.LGFunction{
18            "add": Add,
19        }))
20    return 1
21}

C実装のLuaでは luaopen_共有ライブラリファイル名 が実行されるのですがそこはGoの命名規則に合わせました。違いはそれくらいですね。

こいつをコンパイルして・・・

1$ cd /home/yuin/tmp/plugin
2$ go build -buildmode=plugin -o plugin.so plugin.go

こうじゃ

1$ glua
2> package.cpath = package.cpath .. ";" .. "/home/yuin/tmp/plugin/?.so"
3> adder = require("plugin")
4> print(adder.add(1, 2))
53

おおおおおおおおおおおおお

普通に動きますね。素晴らしい。ちなみに、「ロードする側」と「ロードされる側(すなわちプラグイン)」のバージョンが違うと以下のようにエラーになります。この判定が結構厳しいので（プラグインが参照していない部分の更新でもダメっぽい）、事前にプラグインをコンパイルしておいて配布、は難しいのではないでしょうか。

1<string>:1: plugin.Open: plugin was built with a different version of package github.com/yuin/gopher-lua

package.loadlib も実装しました。

1$ glua
2> print(package.loadlib("/home/yuin/tmp/plugin/notfound", "foo"))
3nil plugin.Open(/home/yuin/tmp/plugin/notfound): realpath failed    open
4> print(package.loadlib("/home/yuin/tmp/plugin/plugin.so", "foo"))
5nil plugin: symbol foo not found in plugin plugin/unnamed-16c3f13f46f4b66b64ad316d78cd61078d12ac64  init
6> print(package.loadlib("/home/yuin/tmp/plugin/plugin.so", "LuaOpenPlugin"))
7function: 0xc4200c9840
8>

完璧ですね。

pluginパッケージ、使えそうですが・・・

少なくとも、Linuxでは plugin パッケージは使えそうです。ただし、本体と共有ライブラリのコンパイル時、完全にバージョンを合わせる必要があるところが難しそう。

Goの大きなメリットである単一バイナリ配布や、クロスコンパイルと相性は悪いですがうまく使っていければいいなと思います。

comments powered by Disqus