あずにゃん (@ Austin Bouldering Project in Austin, TX) https://www.swarmapp.com/osa_k/checkin/5cc6251e00b068002d6ff4ba?s=rNrrSvq_xMJTrM86pKc-M3j993k
あずにゃん (@ Austin Bouldering Project in Austin, TX) https://www.swarmapp.com/osa_k/checkin/5cc6251e00b068002d6ff4ba?s=rNrrSvq_xMJTrM86pKc-M3j993k
あずにゃん (@ Tino's Greek Cafe in Austin, TX) https://www.swarmapp.com/osa_k/checkin/5cc63db6d4cc98002c947182?s=cuoS-mSXj25zZmVU7nt5Yg32EfA
gtk_mainのセマンティクスよくわからんな、なんでModal dialogが閉じるのを待ち受けるのに新しいイベントループが必要なの?
ダイアログが閉じたのを非同期でメインに返すのが面倒だからイベントを処理してる最中のスレッドはそこで止まってほしいが、UIのメッセージポンプ自体が止まると困るみたいな話なのかなあ。でもモーダルが開いた時点でメインのウインドウ宛に投げられてたメッセージはどうなるんだ?
気を抜くとスレッドって言ってしまうけど、実際はGTKのメッセージループってマルチスレッドでもFiberでもなく一本道だよね?
FiberError fiber called across stack rewinding barrierを再現するやつができました https://github.com/osak/mikutter_fiber_crash
そうだとするとmikutterはguiをプラグイン経由でいじるからDelayer経由になって、GTK触るのは必ずメインスレッドになるのか(よくできてるなぁ)
@tsutsuii 確かに、delayer-deferredは複数のスレッドがキューを消化し得る設計のアプリケーションだとそれだけでFiberError出して死ぬ気がするので、そっちを直すのは正しそうですね
@toshi_a なるほど……guiプラグイン導入当初は何が嬉しいのかあんまり分かってなかったけど、今になって分かってきました。GTKは闇
「Dialog#run は Blocks in a recursive main loop until the dialog either emits the response signal, or is destroyed. とのことだが再帰メインループレベルはインクリメントされない」 めっちゃ闇の臭いがするしなんならGTKのチュートリアルとも食い違っていてかなりヤバそう http://toshi-a.hatenablog.com/entry/2017/08/30/070435
もしかしてDialog#runを使うとダイアログの上で何か起こるまでメッセージキューを消費しない感じなのか?だとするとダイアログ閉じないと死なないのも分かる気がする(さっきのプラグインはGtk::mainじゃなくてDialog#runで走るやつのため)
@toshi_a UIは並びが重要だからスレッドセーフにしたいなら結局ロックする必要があるので、それでレスポンス悪くなるくらいならスレッドセーフじゃないことにしようというのはまあ分かる気がするし、Xを直接触る人(GTKコミッタ含む)は言わなくても当たり前でしょとか思ってそう
うおおまじか、gtk_dialog_runはgtk_mainじゃなくてg_main_loop_runを直接呼んでるやんけ!!! https://gitlab.gnome.org/GNOME/gtk/blob/master/gtk/gtkdialog.c#L1201
チュートリアルだと思ってたやつドメインをよく見たら公式じゃないな。雑な解説を引いただけだった https://book.huihoo.com/gtk+-gnome-application-development/sec-modaldialogs.html
スキーマ言語の重要性、腑に落ちた / 今さらProtocol Buffersと、手に馴染む道具の話 https://qiita.com/yugui/items/160737021d25d761b353 #Qiita