On 22.01.2013 21:11, zeljko wrote:
On Tuesday 22 of January 2013 19:04:43 Anton Kavalenka wrote:
On 22.01.2013 20:56, zeljko wrote:
On Tuesday 22 of January 2013 18:52:31 Anton Kavalenka wrote:
Dear Lazarus developers!
I'm examining the problem disturbing me for years.
GTK2 applications provide thread-safety using internal mutexes passed
through gdk_thread_init()
And it works.
Pure X-Applcation does so (orders X-messages per-thread) using
XInitThreads at early start of application.
And it also works
But GTK Widgetset uses pure Xlib calls for determining keyboard states.
Xlib thread-safety is not initialized in GTK2 widgetset.
IMO the problem half-way to resolve - either not use Xlib calls (pure
GTK2,3 - it is threadsafe) or make GTK and Xlib interoperable.
Or block GTK calls until Xlib call returned.
Feel free to provide patch.
zeljko
I'd like to, but i'm not a great expert in X - so i've subscribed to the
list to discuss.
using XinitThreads at start of the program blocks GTK painting.
Forms are shown, but no text output.
So - no way to alter XLib internals. The only way - to initialize GTK
threading in a way compatibel with X.
So no way to use critical sections while calling xlib directly ?
Can you open an issue and attach example ?
z.
http://www.remlab.net/op/xlib.shtml
They say - there is a way
Xlib provides two groups of functions for multi-thread use:
/* Thread-safety for global data */
Status XInitThreads(void);
/* Thread-safety for an individual display */
void XLockDisplay(Display *display);
void XUnlockDisplay(Display *display);
GNOMErs blame Xlib
https://mail.gnome.org/archives/gtk-list/2007-November/msg00122.html
I'll try to provide example.
Actually GUI does not need the multhreading.
But rendering into TBimap invokes Xlib calls as side effects.
So no way to compose off-screen.
regards,
Anton
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
