[vlc-devel] [PATCH 00/10] Item browsing system

[Rémi Denis-Courmont]

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 
> in
> 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 
> issue.

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 
> the
> event management mechanism and the gc should allow for implementing 
> it
> ? I mean, the worst case is when an item is currently being played 
> and
> 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.

-- 
Rémi Denis-Courmont