On 01/31/2011 04:14 PM, Tiago Vignatti wrote:
On 01/31/2011 04:06 PM, ext Julien Cristau wrote:
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.

well, as you can see above ("I do agree with Julien in the sense"), I partially agreed with you. Nothing to worry here :)


I understand what you're trying to solve, I
disagree that an xlib configure option is the way to go.

cool that you understand. So could you suggest and recommend another better way for everyone then?

    Tiago

Would it be possible to guard against misbehaving applications by making it possible to configure libX11 with a dummy mutex?

typedef int dummy_mutex;

void lock(int *m) { assert(++(*m) == 1); };
void unlock(int *m) { *m = 0 };

It's not perfect but I guess it would be better than crashing in some random place in libX11.

-- Rami

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to