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
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
