You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: