[AD] Fwd: RE: Working on ex_threads, d3d_display

Subject:

RE: [AD] Working on ex_threads, d3d_display_format.cpp, tls.c

Date:

Sun, 21 Aug 2016 17:37:56 -0600

From:

To:

Edgar Reynaldo <edgarreynaldo@xxxxxxxxxx>

First of all, Elias can you confirm why you wanted this in TLS? I guess it allows displays to be created in parallel, which might be a tiny advantage, though this should run pretty quickly (instantly?)

But if we do go with a mutex, you can create it in d3d_init_display and destroy it in d3d_shutdown_display in d3d_disp.cpp. Declare it in d3d.h in src/win, not in include/allegro5 anywhere.

From: Edgar Reynaldo
Sent: August 21, 2016 5:01 PM
To: trent@xxxxxxxxxx
Subject: Re: [AD] Working on ex_threads, d3d_display_format.cpp, tls.c

On 8/21/2016 5:55 PM, trent@xxxxxxxxxx wrote:

I think that is the simplest approach, if I’m not missing anything on why TLS was suggested to begin with.

From: Edgar Reynaldo
Sent: August 21, 2016 4:25 PM
To: trent@xxxxxxxxxx
Subject: Re: [AD] Working on ex_threads, d3d_display_format.cpp, tls.c

On 8/21/2016 5:18 PM, trent@xxxxxxxxxx wrote:

It wouldn’t hurt to create an aintern_tls.h. As for tls_get returning NULL, you’d have to return an error to the user (eg return false or NULL, not sure the specifics.) But perhaps it would be better to use a mutex here. There’s no real reason this needs to be in TLS.

So you would prefer to keep eds_list, fullscreen, and adapter static and then access them with a mutex? That would serialize the creation of the displays in ex_threads then, which is fine, and would solve the crash.

Okay, then that raises the question of the mutex to provide locking for d3d_display_formats.cpp then. As the mutex needs to be created and initialized, and a destructor added for it. Where and when should the mutex be created and initialized? And does a destructor for the mutex need to be registered? Does allegro destroy mutexes when at_exit or al_uninstall_system is run?