We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3660

Summary: SDL_Log() isn't thread safe.
Product: SDL Reporter: Ryan C. Gordon <icculus>
Component: *don't know*Assignee: Ryan C. Gordon <icculus>
Status: ASSIGNED --- QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: HG 2.0   
Hardware: All   
OS: All   

Description Ryan C. Gordon 2017-05-29 21:05:14 UTC 
Right now, we call through to either a default platform implementation that may or may not be thread safe (OutputDebugString or fprintf might be, the PSP code that fopen/fwrite/fclose a log file on each call probably isn't), or a application callback where anything goes.

To make sure the logging doesn't race for resources (and so two lines of logging don't intersperse, etc), we should probably wrap the callback in a mutex.

--ryan.
Comment 1 Ryan C. Gordon 2017-08-09 05:25:35 UTC 
(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.6.

This means we're in the final stretch for an official SDL 2.0.6 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.6 release, and generally be organized about what we're aiming to ship. After some debate, we might just remove this tag again and deal with it for a later release.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.
Comment 2 Sam Lantinga 2017-08-11 17:41:04 UTC 
This can be fixed post-2.0.6. The default log function on the major platforms is already thread-safe.

We should be careful that any locking we do is safe to do recursively in case the logging function itself outputs an SDL log message. Maybe we should add a test case for this?