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.
Cheers, Julien _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
