Qt->glib main event loop patch (common main loop)

[nf2]

Aaron J. Seigo wrote:

>On Thursday 10 November 2005 14:37, Martijn Klingens wrote:
>  
>
>>On Thursday 10 November 2005 20:35, Leo Savernik wrote:
>>    
>>
>>>Am Sonntag, 6. November 2005 23:22 schrieb nf2:
>>>      
>>>
>>>>http://www.scheinwelt.at/~norbertf/common_main_loop/
>>>>        
>>>>
>>>Does it link against glib?
>>>      
>>>
>>Does it matter?
>>    
>>
>
>what matters IMHO would be (in random order):
>
>what are the performance implications?
>	memory usage?
>	start speed?
>	runtime speed?
>  
>
I think this question can be answered by looking at the glib main loop 
code.

http://cvs.gnome.org/viewcvs/glib/glib/gmain.c

In fact, glib main loop is nothing but a more sophisticated poll 
statement, which calls back prepare() before polling the 
filedescriptors, and check() and dispatch() afterwards. Considering 
there is only one mainloop per thread, the memory-usage is negligible.

>would trolltech be interested in adjusting the event loop in this way? 
>(otherwise, why bother?)
>  
>
it would be very helpful if they were interested, but they don't have to 
be. it's free software. there are not that many versions of Qt, and the 
QEventloop code hardly ever changes. therefore patching could be an 
acceptable solution (for the beginning). It seems Qt gets patched quite 
a lot. I can see almost 50 patches in the source RPM (mandriva).

>is this cross platform? it seems from a glance at the patch that the answer is 
>'no', meaning that this would be UNIX (and, furthermore, X11 due to calls 
>like XPending) specific and not have the same properties on other platforms. 
>which then begs the question: is that desirable?
>  
>
That's because QEventloop code is not cross-platform and not free of GUI 
related code (at least in Qt3). in fact the ./configure decides, which 
source-files are used for QEventloop. Secondly, the "common main loop" 
is only required for the "free desktop" (unix/x11).

btw: glib main loop is free of graphical toolkit stuff and is cross 
platform. its only dependency is glibc (on unix).

>is it binary compatible? e.g. can a binary built against a glib-event-loop qt 
>run against a vanilla qt and vice versa? looking at the patch it seems so, 
>but figured i should ask anyways.
>  
>
yes. i think so. i'm adding public methods to the QEventloop class, but 
they are just for internal use (cause i can't call private methods from 
C). i haven't recompiled my KDE, and with the patched Qt it's still running.

>will this work as well with Qt4 as it is with Qt3? (otherwise, why bother?) 
>this includes being able to support all the event loop related features in 
>Qt4 (important for things like thread-specific event loops).
>
>  
>
i think that's the most important question. the next thing to have a 
look at is Qt4. i started with Qt3, because i thought it would be a nice 
proof of concept to see the whole KDE running with the patch.

glib main loop has supported thread specific event loops forever (i 
think it has been designed to be multi-context) - therefore i would 
expect that a port is possible.

if anyone could help me with this undertaking or point me to the right 
people at trolltech i would be glad.

norbert