On Fri, Jul 2, 2010 at 11:17 AM, Cedric BAIL <[email protected]> wrote: > 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.
It can call. Just send the files unchecked to main thread, then check with efreet there and ignore paths there. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
