[JIRA] Resolved: (SNOW-445) SDL and X windows are not being handled in a thread-safe way, while the code suggests they are.
Tofu Linden (JIRA)
no-reply at lindenlab.cascadeo.com
Mon Jan 18 14:00:26 PST 2010
[ http://jira.secondlife.com/browse/SNOW-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tofu Linden resolved SNOW-445.
Resolution: Won't Finish
We totally, totally don't expect that random parts of our code are thread-safe unless otherwise noted. We should not be calling anything in llwindow from outside of the main thread. (If we ever did care, retrofitting thread-safeness would have to be much deeper than simply putting locking around some API calls!)
If you think we're calling into llwindow from multiple threads, please file those cases separately!
> SDL and X windows are not being handled in a thread-safe way, while the code suggests they are.
> Key: SNOW-445
> URL: http://jira.secondlife.com/browse/SNOW-445
> Project: 6. Second Life Snowglobe - SNOW
> Issue Type: Bug
> Components: Source Code
> Affects Versions: Snowglobe mysterious future
> Environment: linux
> Reporter: Aleric Inglewood
> Calls to functions of libX11 are not thread-safe. The appropriate way to deal with this is to "lock the display" then do calls that might send messages to the X server, end with a call to XSync to flush all messages to the X server and then "unlock the display". During this lock, other threads should not be able to send messages to the X server (or rather, call functions of libX11).
> The viewer uses libsdl. This library also does calls to libX11 (as does the viewer here and there). Unfortunately, libSDL assumes it's the only library that does calls to libX11: the ONLY thing it does when calling functions of libX11 is calling the functions pair SDL_Lock_EventThread / SDL_Unlock_EventThread. The meaning of these functions is "stop the Event Thread from calling libX11 functions". The reason that this normally works is because normally the event thread exists and locks/unlocks an internal lock called "SDL_EventLock", while a call to SDL_Lock_EventThread locks the same lock if the event thread exists. Thus, as long as the event thread exists, SDL_EventLock is locked around every libX11 call.
> The viewer also does calls to libX11 directly. Whenever it does this, it calls "maybe_lock_display() / maybe_unlock_display()", this function then calls the lock/unlock functions that were obtained from libSDL as function pointers, which turn out to be SDL_Lock_EventThread / SDL_Unlock_EventThread.
> So far so good, but now the problem: The viewer has it's own mainloop, and calls SDL_PollEvent() instead of having libsdl run it's own loop by this "event thread". In fact, SDL_PollEvent calls SDL_PumpEvents which does nothing unless the event thread does NOT exists.
> So, in our case there is NO event thread and SDL_Lock_EventThread / SDL_Unlock_EventThread do *nothing* (and thus maybe_lock_display / maybe_unlock_display does nothing): There are NO locks around calls to ANY libx11 call. We can't even add a lock ourselves because calls to SDL do internal calls to libX11 and we can't make them set a lock without creating this event thread, which wouldn't work because it's existance changes how libsdl works. A work around would be to set locks around every call to libsdl, but well...
> The conclusion has to be that we CANNOT, ever, call libx11 OR libsdl functions from anything but the main thread.
> The "bug" therefore is the existance of "maybe_lock_display / maybe_unlock_display" and the whole code that configures the functions pointers that these functions call: that gives the idea that this would be thread-safe, but it isn't and cannot be.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://jira.secondlife.com/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the Jira-notify