In order to call gtk-functions from side-threads, one is supposed to use within-gtk-thread. This leads to a stable-pointer being set up with a lambda, which a callback then funcalls, and cleared by the finaliser of gdk-threads-add-idle-full. This is (claimed to be) thread safe within gtk, but the accesses to the 'stable-pointer'-variable are not safe. So if more than one Lisp-thread uses within-gtk-thread at the same time, one can end up with source-func-cb funcalling nil.
Putting mutex-locks around all uses of within-gtk-thread in user code will solve the issue, but it would be nicer to have it around just the stable-pointer access.
I'm not comfortable enough with multi-threading to propose to code achieve this, though. Sorry.
In order to call gtk-functions from side-threads, one is supposed to use within-gtk-thread. This leads to a stable-pointer being set up with a lambda, which a callback then funcalls, and cleared by the finaliser of gdk-threads-add-idle-full. This is (claimed to be) thread safe within gtk, but the accesses to the 'stable-pointer'-variable are not safe. So if more than one Lisp-thread uses within-gtk-thread at the same time, one can end up with source-func-cb funcalling nil.
Putting mutex-locks around all uses of within-gtk-thread in user code will solve the issue, but it would be nicer to have it around just the stable-pointer access.
I'm not comfortable enough with multi-threading to propose to code achieve this, though. Sorry.