[Xcb] how should Xlib handle threads?

[Barton C Massey]

I'm obviously not understanding.  Why not just provide a
call in the XCB API that does what Xlib wants, i.e. queues a
request and assigns a sequence number?  Doesn't XCB already
know how to do this pretty well?

	Bart

In message <20051224120020.GK7650 at id.minilop.net> you wrote:
> 
> --===============0450437683==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature"; boundary="OQhbRXNHSL5w/5po"
> Content-Disposition: inline
> 
> 
> --OQhbRXNHSL5w/5po
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> The new Xlib-specific XCB API provides an accessor for XCB's I/O mutex
> so that Xlib can use the same mutex as its display lock, and so Xlib can
> overwrite XCB's normal mutex with a "recursive" or "counting" mutex.
> 
> pthread_mutex_t *XCBGetIOLock(XCBConnection *c)
> {
>     return &c->iolock;
> }
> 
> Two problems: I really don't want Xlib hooked in that closely, and I
> really don't want to be using recursive mutexes. What should I do?
> 
> The reason Xlib currently needs to share XCB's I/O lock is because
> whenever the Display is locked, Xlib might queue a request and assign a
> sequence number, and it does both things without getting XCB involved.
> If at the same time another thread calls XCB directly to queue a request
> and get a sequence number, then the client may believe both requests
> have the same sequence number, which leads to an assertion failure soon
> afterwards. As of today, I don't believe Xlib needs to execute anything
> else atomically with respect to XCB.
> 
> I've contemplated two strategies so far. Both have... issues. I'm
> certainly open to more alternatives.
> 
> First, we could try having Xlib maintain a virtual sequence number
> stream and a map from virtual sequence numbers to the real ones that XCB
> wound up assigning to the same requests. This entirely solves the
> problem (I think), doesn't require any changes to XCB, reduces
> contention between threads, and addresses XCB's occasional need to
> spontaneously generate requests without Xlib's permission. On the other
> hand it seems potentially hard to implement correctly, and the concept
> of a purely fictional sequence number stream is just weird.
> 
> Or, we can implement a lock in XCB that protects only sequence-number
> allocation and request queueing. As far as I can figure it, Xlib has to
> be able to hold this lock while the Display is locked, and acquire it a
> second time once Xlib has figured out it has bits to send. In other
> words, this calls for essentially a recursive mutex. It can be
> implemented as a condition-variable based pseudo-lock instead, but it's
> pretty ugly however you do it. And it doesn't solve all the issues.
> 
> Any fix for this problem reduces the Xlib-specific APIs in XCB to a
> single function, and that function might conceivably be useful to real
> applications, which would be a really nice result.
> 
> So. Help?
> 
> --Jamey
> 
> --OQhbRXNHSL5w/5po
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> 
> iD8DBQFDrThUp1aplQ4I9mURAvIYAJ98FOlmpJSxTca9w1+LknDfI6YE8ACggGjK
> prcfnFrcf2JXkkjL4IAm28Q=
> =++Y8
> -----END PGP SIGNATURE-----
> 
> --OQhbRXNHSL5w/5po--
> 
> --===============0450437683==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
> --===============0450437683==--