On Fri, Jul 2, 2010 at 3:44 PM, Gustavo Sverzut Barbieri
<[email protected]> wrote:
> On Fri, Jul 2, 2010 at 8:17 AM, Enlightenment SVN
> <[email protected]> wrote:
>> Log:
>> * ephoto: use ecore_long_run instead of idler to do async blocking IO.
>>
>> Author: cedric
>> Date: 2010-07-02 04:17:59 -0700 (Fri, 02 Jul 2010)
>> New Revision: 49995
>>
>> Modified:
>> trunk/ephoto/src/bin/ephoto_thumb.c
>> trunk/ephoto/src/bin/ephoto_thumb_browser.c
>>
>> Modified: trunk/ephoto/src/bin/ephoto_thumb.c
>> ===================================================================
>> --- trunk/ephoto/src/bin/ephoto_thumb.c 2010-07-02 11:15:20 UTC (rev 49994)
>> +++ trunk/ephoto/src/bin/ephoto_thumb.c 2010-07-02 11:17:59 UTC (rev 49995)
>> @@ -136,6 +136,9 @@
>> NULL,
>> NULL,
>> NULL,
>> + NULL,
>> + NULL,
>> + NULL,
>> NULL
>> };
>
> no, avoid these fixes. Move it to use the macro instead. The macro
> will avoid having to do these fixes in the future.
>
> Okra: also, please consider looking in evas's box/table smart objects,
> and clipped smart object. They will likely save you time. And use the
> Evas_Smart_Class::calculate instead of your configure. To mark it as
> changed to have this method call before render time, just call
> evas_object_smart_changed()
I will let okra just fix that one.
>> + while ((d = readdir(ed->direc)))
>> + {
>> + if (ecore_thread_check(thread)) break;
>> +
>> + path = malloc(sizeof (char) *
>> + (strlen(ed->dir) + 2 + strlen(d->d_name)));
>> + if (!path) continue;
>> +
>> + strcpy(path, ed->dir);
>> + strcat(path, "/");
>> + strcat(path, d->d_name);
>
> ouch, this is not good... check how it is done in ecore_file,
> basically you know the first part (ed->dir + '/') is invariant, so
> save it, then override the last part and knowing the full size (with
> d_name) you malloc + memcpy, it is faster as you do bigger copies at
> once, code will be simpler as well. strcat needs to walk it to the
> end, so it is stupid to call it.
Just a quick written piece of code before I find a proper solution.
> Maybe ecore_file_ls() could have a counterpart like
> ecore_file_ls_iterator(), then we can benefit from its code and be
> able to abort until it gets to the end?
Good idea, I was thinking about doing just that. And it's a good thing
to remember us we should use more iterator and accessor.
>> + type = efreet_mime_type_get((const char *)path);
>
> cedric, I really don't think efreet mime_type_get() is thread-safe :-/
Well I followed as much path I could in the code, and it seems to be
safe, but yes, I agree I have no garanty. But I would prefer to fix
this the other way around, if possible without increasing Efreet cost
to make it thread safe.
> maybe move this to the main thread?
Do you know if elementary does call efreet in the background ? If not,
then that's the only current user in ephoto, and their is only one
thread running, so safe for the moment.
--
Cedric BAIL
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
