| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 4 | |
Hi Everyone. Should I call XInitThreads() manually ? My app hangs with this call on one machine and hangs without this call on other one ... -- [ signature omitted ]
Dmitry Samersoff wrote: > Hi Everyone. > > Should I call XInitThreads() manually ? > > My app hangs with this call on one machine and hangs without this call > on other one ... > Just out of curiosity. Does it crash on a Fedora machine? -- [ signature omitted ]
Andrà Lemos wrote: > Dmitry Samersoff wrote: >> Hi Everyone. >> >> Should I call XInitThreads() manually ? >> >> My app hangs with this call on one machine and hangs without this call >> on other one ... >> > Just out of curiosity. Does it crash on a Fedora machine? Both problem machines is Gentoo ones. On Solaris 10 box works fine with or without this call. -- [ signature omitted ]
Hi, > Should I call XInitThreads() manually ? > > My app hangs with this call on one machine and hangs without this call > on other one ... Indeed, as far as I know XInitThreads() tends to be broken on some platforms, involving some X11 extensions such as XIM or Xprint. See for example: http://lists.trolltech.com/qt-interest/2001-05/thread00135-0.html http://lists.trolltech.com/qt-interest/2003-07/msg00783.html http://code.google.com/p/qshaderedit/wiki/ThreadingProblems http://mail.gnome.org/archives/gtk-list/1999-July/msg00313.html I'm not sure about the current status of this issue on recent Linux platforms. -- [ signature omitted ]
Dimitri wrote: > Hi, > >> Should I call XInitThreads() manually ? >> >> My app hangs with this call on one machine and hangs without this call >> on other one ... > > Indeed, as far as I know XInitThreads() tends to be broken on some > platforms, involving some X11 extensions such as XIM or Xprint. See for > example: XInitThreads initilaize _XLockInfo struct with pointers to mutex'es and locking functions, which is actually pthread_mutex_lock/unlock under Linux. XIM problem is completely different: XIM lock display, then call callback function if callback function also tries to lock display everything hangs. It's X11 bug existing from pre-historic time. Solaris implementation is much better and don't have issues mentioned above. As far as I understand QT calls not so many X functions and do a lot by it's own. Also QT uses it's own mutex/locking (down to cmpxchgl under x86). Therefore the only reliable solution for QT is use it's own mutex outside of XLib calls and never touch native X locking (XInitThreads). I'm not sure whether QT developers did it or not. -- [ signature omitted ]
Dmitry Samersoff wrote: >As far as I understand QT calls not so many X functions and do a lot by >it's own. Also QT uses it's own mutex/locking (down to cmpxchgl under >x86). Therefore the only reliable solution for QT is use it's own mutex >outside of XLib calls and never touch native X locking (XInitThreads). > >I'm not sure whether QT developers did it or not. We have our own locks whenever necessary. But since the X11 entry points are only used from one thread, there isn't much of a need for locking. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Hi, > XInitThreads initilaize _XLockInfo struct with pointers to mutex'es and > locking functions, which is actually pthread_mutex_lock/unlock under Linux. > > XIM problem is completely different: XIM lock display, then call > callback function if callback function also tries to lock display > everything hangs. It's X11 bug existing from pre-historic time. I was actually referring to the problem that X11 extensions (XIM is only one such example) hang when calling XInitThreads(). This is different from the problem you're describing above. -- [ signature omitted ]