[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!

Thanks!

> 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 mailing list