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: [email protected] Subject: Re: [AD] Working on ex_threads, d3d_display_format.cpp, tls.c On 8/21/2016 5:55 PM, [email protected] 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: [email protected] Subject: Re: [AD] Working on ex_threads, d3d_display_format.cpp, tls.c On 8/21/2016 5:18 PM, [email protected] 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: [email protected] 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: [email protected] Cc: Allegro Developers Subject: Re: [AD] Strange timer behavior in 5.2.1.1 On 8/21/2016 3:41 PM, [email protected] 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
_______________________________________________ Allegro-developers mailing list [email protected] https://mail.gna.org/listinfo/allegro-developers
