2011/9/2 Vincent Torri <vto...@univ-evry.fr>: > > > On Fri, 2 Sep 2011, Cedric BAIL wrote: > >> On Fri, Sep 2, 2011 at 2:29 AM, Gustavo Sverzut Barbieri >> <barbi...@profusion.mobi> wrote: >>> >>> Hello all, particularly Cedric. >>> >>> Before I explain the annoying problem in consequence of it, let me say >>> that I totally disagree with storing playback position in file xattr. >>> This kind of thing should be per application, not per file. >>> 1- Let's say you thumbnail a file using emotion, you'll get file >>> changed. >>> 2- Let's say you don't want to remember it. You'll still get file >>> changed. >>> 3- You'll be hitting the disc (or flash) more than desired. >>> >>> So please remove such thing from Emotion, it's really not there. If >>> you wish you can make it an optional API call that the application may >>> give its own xattr key and it's persisted. But really, any application >>> should have its own database as xattr is not available everywhere and >>> they will get lots of bugreports with inconsistent behavior. >> >> Of course it is an optional call that the application is doing. That >> what emotion_object_last_position_save is doing. The idea is to be >> able to thumbnail at the last saved position if you want it and share >> this information with all other application without the need to track >> if the file still exists or not. And ethumb emotion is not calling the >> emotion_object_last_position_save. >> >>> But let's spot the actual bug, which is VERY annoying if you're using >>> generic engine: >>> - you operate on threads using eio, those are marked as >>> PTHREAD_CANCEL_ENABLE && PTHREAD_CANCEL_ASYNCHRONOUS >>> - you get tons of position changed, so the thread is often running >> >> How is that possible ? What application are you using ? This thread >> should only be called on object destruction or something like that. >> >>> - you increment the reference count of emotion >>> - you quit your application (emotion_test) >>> - thread is running, sd->refcount is 2 >>> - _smart_data_free is not called >>> - sd->module->file_close() is not called >>> - plugin->close() is not called >> >> That's strange, here my application stop until the thread come back. >> Will debug it, but solution is quite easy. >> >>> Then there is no way to communicate the slave should die and it keeps >>> playing until buffer fills. >>> >>> Yes, there are ways to make the slave die... but damn it... this thing >>> with xattr is insane! >> >> Not necessary, better fix the thread call. > > i don't know that xattr stuff, but i'm wondering if it exists on Windows >
HAHAHAHHA You are so funny sometimes... > Vincent > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
