[vlc-devel] [PATCH 00/10] Item browsing system
remi at remlab.net
Tue May 27 10:20:29 CEST 2014
Le 2014-05-27 16:07, Julien 'Lta' BALLET a écrit :
> Currently, i dont pass the fd from the access to the browser.
I consider that a design problem. That's exactly my point.
> On the other hand, for remote browsable node, sharing a state would
> actually be pretty nice to speed things up.
It's not only performance. It also addresses TOCTOU issues, is a
necessary enabler for updating nodes content, and may be necessary in
some cases depending on the protocol and/or the library (UPnP possibly).
> A solution could be adding a vlc_object_t state to the input_item_t
> order to store a state, its origin and handling its cleanup.
I think any solution that revolves around input_item_t is absolutely
doomed to FAIL. If only because the playlist currently leaks all input
items forever (that is to say until VLC exits), and we may not be able
to keep thousands of outstanding file handles or what-nots.
>> Not to mention the hypothetical thread running inotify to detect
>> asynchronous changes to the directory content. That also needs some
>> life cycle management and can obviously not be serialized.
> I never wanted to serialize anything. Im trying to _remove_ xpsf
> serialization :)
You *are* serializing the directory access. Previously it was all done
via the non-serialized file handle of the directory. Now it's done with
the directory path, in other words serialized data.
> This asynchronous inotify thread seems to me like a whole other
It's exactly the same. To update the node, you need to associate opaque
state (and possibly a thread) with it. This is true for inotify if ever
implemented, and this is also true for UPnP. The service discovery
supports updating nodes asynchronously, and it's heavily used; you
cannot simply remove the feature.
> Im not sure i realize all the implications of it. But i kinda feel
> event management mechanism and the gc should allow for implementing
> ? I mean, the worst case is when an item is currently being played
> it gets deleted but in that case, either the system will wait for the
> last fd to be closed to actually delete the item or the access will
> fail and well be able to release the item, no ?
I can't speculate on that.
More information about the vlc-devel