# To subscribers of the xforms list from Steve Lamont <spl@ncmir.ucsd.edu> :
> . . . To explain the problem I have included
> here your demo 'minput.c' in which I added a very simple thread that
> prints a message. If I use now XInitThreads() the process remain
> blocked when you try to give an input from keyboard (also if the
> thread continues to run well) and any interaction with the form is
> lost. If I comment XInitThreads() all run well. . . .
Hm. I've just tried it under Red Hat Linux and have been able to
duplicate the problem. It also completely hangs under SGI IRIX64 6.5.
However, it runs fine under FreeBSD and Solaris, so go figure.
According to the XInitThreads() man page
[. . .]
It is only necessary to call this function if multiple
threads might use Xlib concurrently. If all calls to Xlib
functions are protected by some other access mechanism (for
example, a mutual exclusion lock in a toolkit or through
explicit client programming), Xlib thread initialization is
not required. . . .
So, if you're only generating XForms and other X calls from the main
thread, then you don't need to call XInitThreads() at all.
Why it works under some implementations and doesn't under others, I
confess I have no idea. According to the debugger it's hanging
waiting for a mutex buried way the heck down in one of the X keyboard
input routines. I don't think it's an XForms problem but wheh I get
the chance I'll try to see if I can isolate it further.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://world.std.com/~xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/
This archive was generated by hypermail 2b29 : Mon Feb 10 2003 - 10:36:46 EST