Re: [AD] Strange timer behavior in 5.2.1.1

[<trent@xxxxxxxxxx>]

This thread got brought into private messages. Elias:

 

--

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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx
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?

 

 

 

From: trent@xxxxxxxxxx
Sent: August 21, 2016 2:52 PM
To: Edgar Reynaldo
Cc: Allegro Developers
Subject: Re: [AD] Strange timer behavior in 5.2.1.1

 

I think the examples used to be built as console applications. I’m not sure why they are now built as Windows apps but maybe somebody knows.

 

 

 

From: Edgar Reynaldo
Sent: August 21, 2016 2:47 PM
To: trent@xxxxxxxxxx
Cc: Allegro Developers
Subject: Re: [AD] Strange timer behavior in 5.2.1.1

 

 

On 8/21/2016 3:41 PM, trent@xxxxxxxxxx wrote:

Thanks for reporting this. Looks like I messed this up. I think this patch will fix it:

 

diff --git a/src/timernu.c b/src/timernu.c

index 9179969..66f1c33 100644

--- a/src/timernu.c

+++ b/src/timernu.c

@@ -104,6 +104,7 @@ static void timer_thread_proc(_AL_THREAD *self, void *unused)

       al_lock_mutex(timers_mutex);

       while (_al_vector_size(&active_timers) == 0 && !destroy_thread) {

          al_wait_cond(timer_cond, timers_mutex);

+         old_time = al_get_time();

       }

       al_unlock_mutex(timers_mutex);

 

 

Can you try this in the PacMan game? Ex_timer_pause won’t work unless you build it as a console app (the examples are now built as Windows applications), but I confirmed it works on Linux.

 

I'll rebuild the debug dll and have Neil test it out. Thanks for the prompt reply.

So what to do about ex_timer_pause? Is there an easy way to rebuild the library examples as console apps to test this? Besides just compiling it myself? I'm using MinGW 5.3.0 (and 4.8.1).

Edgar