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?
> 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
Without VGL the connection mutex inside the real xcb_get_extension_data
would block so this code would work. But the above method in VGL with a
per-connection instead of per-thread flag will give incorrect results,
right? (Both expect to be faked, but only one is.)
If we added a mutex to the faker function so we get the same blocking
behaviour that the underlying implementation relies on then we'd have to
store the current thread id along with the "already faked" flag and use
e.g. pthread_mutex_trylock first so reentrant calls on the same thread
wouldn't block. That's so ugly I don't want to think about it.
TLS seems really tempting.
-Nathan
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
