[Xcb] Is there anyone out there ?

[Jamey Sharp]

--e7WmlSfQJTtHfSol
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 09/30 02:09AM, kha wrote:
> Quoting Jamey Sharp <jamey@cs.pdx.edu>:
> > On 09/29 08:30PM, kha wrote:
> > > 1) Cookies system going through SHM in a full assynchronious yet
> > > remanent form.  Allow me to explain : from what I understand right
> > > now cookies are sent with a priority
> >=20
> > I'm having a really hard time understanding what you want, but I
> > suspect this is the problem: responses always come back from the
> > server in the same order as you sent the requests, and cookie forces
> > always return as soon as possible after the response arrives.
> > There's no priority to set, if I understand what you mean by that.
>=20
> Ok it is not really a priority system, but from what I understood
> there is a "as soon as you can" cookie and a "I NEED IT NOW" cookie.=20

Well, you can't ever get a reply from the server any faster than it was
going to come anyway. So the response to "ININ" is "tough, it's coming
as soon as I can". So no, there's only one class of cookie.

> My concern is that cookies being sent to the manager are "lost" to the
> app.  Which can lead to an app requesting a "ININ" cookie while its
> demand is actually being processed.

This is a potential problem in multi-threaded applications using XCB,
yes. It can't ever happen in a single-threaded app, because when the app
forces a cookie, the app blocks until the response arrives. In a
multi-threaded app, the cookie could conceivably be in memory shared
between two threads, in which case a poorly-written app could try to
force the same cookie in two threads at once. This is a bug in the app,
though, and only requires the app to use a mutex or something.

> Another thing that bothers me is that for some small yet reccurent
> requests a cookie has to be sent each time. A shared memory segment
> would allow to let an app keep track of its requests and would also
> permit to repeat the same task infinitly without actually reissuing
> the cookie.

What sort of requests recur? And how would XCB know when to re-send the
request? I still don't understand this.

If it is something that would be useful, it sounds like it just has to
be a library built on top of XCB, maybe using a separate thread to make
the requests. I don't think you need a shared memory segment; remember,
since XCB is a library on the client side, it's in the same memory space
as the client application.

> Technically this system would definitly involve some rewriting. But I
> think it could be worth it.=20

Hey, re-writing is fine. It doesn't strike me as necessary in this case,
though. Maybe when I understand what you want...

> > Well, that's something that needs work, and we'd love for you to
> > play with it. :-) I'm not entirely familiar with the details of 3D
> > rendering in X, but I believe we need somebody to implement the GLX
> > extension in XCB, and then to port Mesa (and ideally GLUT) to use
> > XCB. With GLUT in place, a lot of 3D apps would just run. (I don't
> > even think they'd need to be recompiled, but I'm not sure.)
>=20
> Glut is not a good idea as far as I am concerned. Glut goal is to mask
> the local layer for display and events scan so that protability is
> reached easily (opening a window and scanning keys is the same under
> windows GLUT and GLUT Linux). But GLUT doesn't bring any GL function,
> it si just a layer to hide. And hiding the functions and API we just
> wrote seems a little akward.

Which was exactly my point: if GLUT works, people can use XCB without
even knowing it. Having real applications running on XCB, even if the
application knows nothing about XCB, is a huge win in terms of getting
XCB tested out "in the wild". I want XCB everywhere, and upgrading the
toolkits gets us the closest to everywhere with the least work.

> But I can implement GLU and Glaux in XCB if you want, that should give
> XCB the all bunch of GL functions that exist out there, and leave
> plenty of space if someoen actually want to write a GLUT lib on top of
> it.=20

That would be great. I'm willing to look at GLUT myself if nobody else
steps forward after you've built the lower-level stuff. We need to get
Gtk+ and/or Qt ported anyway; after those, porting one more toolkit
surely isn't that big of a deal.
--=20
Jamey Sharp <jamey@minilop.net> - http://minilop.net/

--e7WmlSfQJTtHfSol
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/eTA0NgAXSpyH6VcRAlIZAJsFflTtCJ0SbMjOzdHdsoJcPtIj0gCeMLOj
SfaNZzWSGgC0dEg8D76ygCg=
=nlyq
-----END PGP SIGNATURE-----

--e7WmlSfQJTtHfSol--