[PATCH] Use gtk_tree_model_get_value() to get the index and date of a dive

Jef Driesen jefdriesen at telenet.be
Thu Sep 20 05:42:34 PDT 2012


On 2012-09-19 19:25, Linus Torvalds wrote:
> On Wed, Sep 19, 2012 at 1:10 AM, Lubomir I. Ivanov
> <neolit123 at gmail.com> wrote:
>>
>> mingw-gcc 4.7, mingw-gcc 4.8 provides some of these in time.h as
>> macros under POSIX (which is what they are):
>>
>> #ifndef gmtime_r
>> #define gmtime_r(_Time,_Tm)     ({ struct tm *___tmp_tm =            
>>   \
>>                                                 gmtime((_Time));     
>>   \
>>                                                 if (___tmp_tm) {     
>>   \
>>                                                   *(_Tm) = 
>> *___tmp_tm;  \
>>                                                   ___tmp_tm = (_Tm); 
>>   \
>>                                                 }                    
>>   \
>>                                                 ___tmp_tm;      })
>> #endif
>
> The above is pure and utter garbage. It doesn't make any sense at 
> all,
> and isn't thread-safe in the least.

It's actually not that bad. You have to consider this is a header file 
from the mingw project, which targets the Microsoft C library (msvcrt). 
Since the Microsoft library is using thread-local storage, the gmtime() 
function is thread-safe. Thus this gmtime_r macro is thread-safe, but 
not re-entrant.

Of course I agree this should be taken care of at the application 
level. That's the only way to have full control over which function you 
are actually using!

> Anyway, none of this is needed. subsurface isn't really 
> multi-threaded
> anyway. The only time you have threads happening is when downloading
> from a dive computer, and during that time the only thing subsurface
> does is to call process_ui_events() in the other thread.
>
> That assumes that the gtk main loop itself doesn't use gmtime(), or
> course, but that had better be a fairly safe assumption.

That's not entirely correct. When you call process_ui_events() on the 
main thread, any gtk+ callback can be executed in response to some GUI 
events. For example the screen can be repainted. But if the listview 
gets repainted, the date_data_func() will get called to render the dive 
datetime. And that function does call gmtime().

BTW, I'm not sure whether you are aware of the fact that you shouldn't 
call gtk+ functions from threads other than the main thread. Doing this 
happens to work on X11, but it's known to break on windows. Subsurface 
is breaking this rule when updating the progress bar from the 
libdivecomputer thread. The correct way to do this is to update the 
progress bar from the main thread with a call to the g_idle_add 
function.

Jef


More information about the subsurface mailing list