On Sun, May 15, 2005 at 05:09:39PM +0300, Martin Vermeer wrote:
> Lars,
> 
> Now that I have had some time to think it over, I am more and more
> inclined to suspect that there is something to my dark fear.
> 
> As I understand it, LyX, Qt and X all process events in a "linear"
> fashion. This means, that routines call subroutines (stacking their
> context), calling subroutines, etc... until they return and unwind their
> contexts. 
> 
> The event loop (X or Qt) is no different.
> 
> Under such a scheme it is _in principle impossible_ for function calls
> in different places in the code to pre-empt each other. The keystroke
> reversal we saw just cannot come about.
> 
> So, _something_ is happening non-linearly, through pre-emption. We know
> of course that this kind of thing is happening on the system level all
> the time (hardware clock interrupt etc., process/thread switching). But
> this is irrelevant for our problem. It would be surprising if the same
> happened inside LyX.
> 
> However... looking at my Makefile, I see 
> 
> QT_CPPFLAGS = -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR
> QT_INCLUDES = -I/usr/lib/qt-3.3/include
> QT_LDFLAGS = -L/usr/lib/qt-3.3/lib
> QT_LIB = -lqt-mt
> QT_VERSION = 3.3.3
> 
> qt-mt, doesn't that mean Qt multi-threading? Or am I holding the wrong
> end of the stick?

Yes, it means multithreading.  However, I wouldn't suspect it of magially
starting to multithread an application.  I always thought that qt-mt merely
supported multithreading - i.e. qt-mt won't mysteriously break *if*
your program is multithreaded, but qt(non-mt) may show some
very strange errors with a multithreaded program.

I don't know qt very well, but this is how mt- and non-mt versions
of other libraries tend to work.  An mt-version is multithread-safe,
while the non-mt version is either older or uses some optimizations
that won't work in a multithreaded environment.  An mt-version
will be thread-safe in that everything either is reentrant code, or
use some sort of semaphore to protect anything that isn't 
automatically thread-safe.

Helge Hafting

Reply via email to