> Date: Mon, 31 Jan 2011 15:06:03 +0100 > From: Julien Cristau <[email protected]> > > On Mon, Jan 31, 2011 at 15:12:29 +0200, Tiago Vignatti wrote: > > > On 01/31/2011 01:13 PM, ext Julien Cristau wrote: > > >On Mon, Jan 31, 2011 at 12:46:56 +0200, Rami Ylimäki wrote: > > > > > >>This change makes it possible to guard a system against a missing > > >>XInitThreads call in X clients. One might argue that this is a client > > >>problem and that all X clients should call XInitThreads if it's > > >>possible that they could use Xlib from multiple threads. However, > > >>experience has shown that it's just too easy for developers to > > >>overlook the need for this call. > > >> > > >This change means that somebody developing their apps on a system with > > >it on will never see they need to call XInitThreads(), and stuff will > > >break when moving to an Xlib without that option. I don't think that's > > >a good idea. > > > > I do agree with Julien in the sense that developers could become > > lazy and in general won't care much anymore about initializing > > thread support. > > > > OTOH, if you pick a Qt application for instance, you will see that > > it is close to impossible to track from a stack trace of 80 > > functions whether XInitThreads() is called properly or not. At the > > same time, it's not a big deal to maintain the support Rami made in > > libX11. So why not? > > > Doesn't sound like you agree with me at all. I just said why not, I'm > not going to repeat it. I understand what you're trying to solve, I > disagree that an xlib configure option is the way to go.
I fully agree with Julien here.
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
