Is SDL_DestroyWindow thread-safe?

I am using SDL in a GC-enabled environment (Mono/.Net), which collects
memory in a GC-specific thread.

I have provided APIs for releasing SDL resources manually and these work
perfectly when called from the main thread. The question is, these be
called from the GC thread, or must they always be called on the main thread?

The APIs in question are:
SDL_DestroyWindow
SDL_DelEventWatch

SDL_DestroyWindow() should be called on the same thread as the one which
created the window.

SDL_DelEventWatch() can be called on any thread, as long as event watchers
aren’t being added or removed and events are not being added at the same
time. In practical terms this means it’s likely this should only be called
on the main thread, since you can’t otherwise generally tell if events are
being added.On Tue, Nov 19, 2013 at 6:46 AM, Stefanos A. wrote:

I am using SDL in a GC-enabled environment (Mono/.Net), which collects
memory in a GC-specific thread.

I have provided APIs for releasing SDL resources manually and these work
perfectly when called from the main thread. The question is, these be
called from the GC thread, or must they always be called on the main thread?

The APIs in question are:
SDL_DestroyWindow
SDL_DelEventWatch


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sam knows the specifics of the implementation more and it may indeed
work, but for Mac (and I think iOS too) in general, AppKit is
generally not thread-safe and NSWindow in particular is explicitly
documented as not thread safe. This means all NSWindow stuff should be
on the main thread (not the one you started on).

https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/10000057i-CH12-123364

However, since Apple went through a phase where they supported Obj-C
garbage collection, where the collector worked on background threads,
you might find it actually works, but with an additional caveat that
Apple is known to break things that are not guaranteed to work with
every new release.

Thanks,
EricOn 11/19/13, Sam Lantinga wrote:

SDL_DestroyWindow() should be called on the same thread as the one which
created the window.


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Oh, sorry, I should correct/clarify something. NSView is the really
dangerous one for the non-main-thread. But usually there is an NSView
attached to an NSWindow. However, I have heard stories in the past
that that non-main-thread NSWindow is problematic. It may be better
now, but this is generally not the common case so I doubt things are
as robust.

Thanks,
EricOn 11/19/13, Eric Wing <@Eric_Wing> wrote:

On 11/19/13, Sam Lantinga wrote:

SDL_DestroyWindow() should be called on the same thread as the one which
created the window.

Sam knows the specifics of the implementation more and it may indeed
work, but for Mac (and I think iOS too) in general, AppKit is
generally not thread-safe and NSWindow in particular is explicitly
documented as not thread safe. This means all NSWindow stuff should be
on the main thread (not the one you started on).

https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/10000057i-CH12-123364

However, since Apple went through a phase where they supported Obj-C
garbage collection, where the collector worked on background threads,
you might find it actually works, but with an additional caveat that
Apple is known to break things that are not guaranteed to work with
every new release.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Thanks for the clarification!

It makes sense that the exact behavior is OS-dependent. This makes things a
little bit more complicated but not really different than e.g. OpenGL where
you cannot release resources in the GC finalizer thread.

My strategy will be to mark a window as dead in the finalizer, but not
directly destroy it. The main thread will maintain a list of weak
references to every SDL window and will periodically purge them.

SDL_AddEventWatch / SDL_DelEventWatch are only called in the window
constructor/destructor respectively and protected by a mutex, so there is
no chance of being called at the same time.

2013/11/20 Eric Wing > On 11/19/13, Eric Wing wrote:

On 11/19/13, Sam Lantinga wrote:

SDL_DestroyWindow() should be called on the same thread as the one which
created the window.

Sam knows the specifics of the implementation more and it may indeed
work, but for Mac (and I think iOS too) in general, AppKit is
generally not thread-safe and NSWindow in particular is explicitly
documented as not thread safe. This means all NSWindow stuff should be
on the main thread (not the one you started on).

https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/10000057i-CH12-123364

However, since Apple went through a phase where they supported Obj-C
garbage collection, where the collector worked on background threads,
you might find it actually works, but with an additional caveat that
Apple is known to break things that are not guaranteed to work with
every new release.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Oh, sorry, I should correct/clarify something. NSView is the really
dangerous one for the non-main-thread. But usually there is an NSView
attached to an NSWindow. However, I have heard stories in the past
that that non-main-thread NSWindow is problematic. It may be better
now, but this is generally not the common case so I doubt things are
as robust.

Thanks,
Eric


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sounds good!On Tue, Nov 19, 2013 at 11:30 PM, Stefanos A. wrote:

Thanks for the clarification!

It makes sense that the exact behavior is OS-dependent. This makes things
a little bit more complicated but not really different than e.g. OpenGL
where you cannot release resources in the GC finalizer thread.

My strategy will be to mark a window as dead in the finalizer, but not
directly destroy it. The main thread will maintain a list of weak
references to every SDL window and will periodically purge them.

SDL_AddEventWatch / SDL_DelEventWatch are only called in the window
constructor/destructor respectively and protected by a mutex, so there is
no chance of being called at the same time.

2013/11/20 Eric Wing

On 11/19/13, Eric Wing wrote:

On 11/19/13, Sam Lantinga <@slouken> wrote:

SDL_DestroyWindow() should be called on the same thread as the one
which

created the window.

Sam knows the specifics of the implementation more and it may indeed
work, but for Mac (and I think iOS too) in general, AppKit is
generally not thread-safe and NSWindow in particular is explicitly
documented as not thread safe. This means all NSWindow stuff should be
on the main thread (not the one you started on).

https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/10000057i-CH12-123364

However, since Apple went through a phase where they supported Obj-C
garbage collection, where the collector worked on background threads,
you might find it actually works, but with an additional caveat that
Apple is known to break things that are not guaranteed to work with
every new release.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Oh, sorry, I should correct/clarify something. NSView is the really
dangerous one for the non-main-thread. But usually there is an NSView
attached to an NSWindow. However, I have heard stories in the past
that that non-main-thread NSWindow is problematic. It may be better
now, but this is generally not the common case so I doubt things are
as robust.

Thanks,
Eric


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If this was Delphi, I’d use the Synchronize method in the destructor to ensure that my cleanup ran on the main thread.? Does Objective-C have something like that available?

Sounds good!

Thanks for the clarification!On Tuesday, November 19, 2013 11:57 PM, Sam Lantinga wrote:
On Tue, Nov 19, 2013 at 11:30 PM, Stefanos A. wrote:

It makes sense that the exact behavior is OS-dependent. This makes things a little bit more complicated but not really different than e.g. OpenGL where you cannot release resources in the GC finalizer thread.

My strategy will be to mark a window as dead in the finalizer, but not directly destroy it. The main thread will maintain a list of weak references to every SDL window and will periodically purge them.

SDL_AddEventWatch / SDL_DelEventWatch are only called in the window constructor/destructor respectively and protected by a mutex, so there is no chance of being called at the same time.

2013/11/20 Eric Wing

On 11/19/13, Eric Wing wrote:

On 11/19/13, Sam Lantinga wrote:

SDL_DestroyWindow() should be called on the same thread as the one which
created the window.

Sam knows the specifics of the implementation more and it may indeed
work, but for Mac (and I think iOS too) in general, AppKit is
generally not thread-safe and NSWindow in particular is explicitly
documented as not thread safe. This means all NSWindow stuff should be
on the main thread (not the one you started on).

https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/10000057i-CH12-123364

However, since Apple went through a phase where they supported Obj-C
garbage collection, where the collector worked on background threads,
you might find it actually works, but with an additional caveat that
Apple is known to break things that are not guaranteed to work with
every new release.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Oh, sorry, I should correct/clarify something. NSView is the really
dangerous one for the non-main-thread. But usually there is an NSView
attached to an NSWindow. However, I have heard stories in the past
that that non-main-thread NSWindow is problematic. It may be better
now, but this is generally not the common case so I doubt things are
as robust.

Thanks,
Eric


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[…]

IIRC, Synchronize is implemented by sending a message to the main
thread, which then executes the code while the “calling” thread waits
for a response.

Unless the language at hand has something similar that’s easy to use,
the easiest and most portable way is probably to implement it using
the SDL event system.On Wed, Nov 20, 2013 at 1:03 PM, Mason Wheeler wrote:

If this was Delphi, I’d use the Synchronize method in the destructor to
ensure that my cleanup ran on the main thread. Does Objective-C have
something like that available?

//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’