On 11/26/14 9:20 AM, Nathan Kidd wrote:
> On 25/11/14 10:46 PM, DRC wrote:
>> TLS support is spotty on non-Linux platforms, unfortunately.
>
> What platforms/issues do you have in mind?
Traditionally, TLS wasn't reliable on non-x86 BSD implementations and
Solaris, but that may be old information. Solaris 10 is still supported
by VGL and will be as long as there is driver support for it, so that's
the platform I would have to test to make sure TLS works properly. Bear
in mind that, until January of 2009, I had to support Solaris 8 and
SPARC platforms as well, so it's likely that whenever my brain jumps to
"something doesn't work on non-Linux platforms", it's because it didn't
work on Solaris 8 or 9.
>> Why couldn't we just use the existing XCB connection hash to maintain an
>> "enabled" state for the XCB faker? Whenever an interposed GLX or X11
>> function is called, VGL will attempt to find the XCB connection
>> corresponding to the Display* argument. If successful, VGL will set a
>> "disable" bit for that connection, then re-enable it before returning
>> from the interposed function. Then the interposed XCB functions can
>> look up the connection in the hash and make sure it has interposing
>> enabled before proceeding.
>
> Consider this sequence:
>
> thread1: xcb_get_extension_data(conn1)
> get_already_faked(conn1) != true
> set_already_faked(conn1, true)
> run on faked connection
>
> thread2: xcb_get_extension_data(conn1)
> get_already_faked(conn1) == true
> run on original connection
>
> thread1:
> set_already_faked(conn1, false)
> return
I see your point. set_already_faked() would only be called from within
Xlib and GLX functions, so your example above is partially bogus, but
you could have something like this:
thread1:
XlibFunction(dpy, ...) {
conn=XGetXCBConnection(dpy);
disable_xcb_faker(conn);
_XlibFunction(dpy, ...);
xcb_function(conn, ...);
enable_xcb_faker(conn);
}
thread2:
XlibFunction(dpy, ...) {
conn=XGetXCBConnection(dpy);
disable_xcb_faker(conn);
_XlibFunction(dpy, ...);
xcb_function(conn, ...);
enable_xcb_faker(conn);
}
disable_xcb_faker()/enable_xcb_faker() would be atomic, but it's
theoretically possible that the entire sequence from thread2 could
execute through enable_xcb_faker() between the time that thread1 calls
disable_xcb_faker() and _XlibFunction() -- i.e. a race condition. So I
concur that TLS is probably the answer.
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
VirtualGL-Devel mailing list
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
