Il 06/05/2013 20:35, mdroth ha scritto: > In the case of the former, I think a wrapper around GLib that we can > instantiate from the command-line line and query properties like TIDs > from is necessary for robust control over event loops and CPU resources. > We get this essentially for free with QOM, so I think it makes sense to > use it. > > In the case of the latter I'm not too sure. Without the QSource > abstraction there isn't much reason not to use the native GLib > interfaces on the underlying GSources/GMainContexts directly. In which > case GlibQContext would only need to be a container of sorts with some > minor additions like spawning an event thread for itself. > > If we ever did need to switch it out in favor of a non-GLib > implementation, it should be a mostly mechanical conversion of > GSource->QSource and adding some wrappers around > g_main_context_prepare/check/etc.
I'm not sure it is that easy, but I agree entirely with everything else. > Also along that line, if we're taking the approach of not adding > infrastructure/cruft until we actually have a plan to use it, it probably > makes sense to make QContext a concrete class implemented via GLib, and we > can move the GLib stuff to a sub-class later if we ever end up with another > QContext implementation. > > Does this seem reasonable? Yes, very much. Paolo
