Re: [AD] Strange timer behavior in 5.2.1.1

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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

 

 



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/