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

[Julien 'Lta' BALLET]

On Tue, May 27, 2014 at 10:20 AM, Rémi Denis-Courmont <remi at remlab.net>wrote:
>
>  Currently, i dont pass the fd from the access to the browser.
>>
>
> I consider that a design problem. That's exactly my point.


Let's admit that was the design that required the minimal amount of
changes, which was one of the initial goal. (Not meaning i don't see you or
diminish your 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).
>

What is toctou ? An island from "pirates of the caribbean" ? (Yes, this is
a joke)
We might want to explain that to playlist (pls, m3u) file writer. Don't use
m3u, it has a TOCTOU issue :) (Another stupid joke)


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

On the other hand, having the state somewhere inside of input_item_t
doesn't mean it has the share the same lifetime. Let's face it, at some
point, any solution not including rewriting the playlist will have to work
at least a little bit with the input_item. I won't say it makes me happy,
but doing otherwise might be out of a realistic time frame for me alone :)
(Any help on that topic is welcomed, please drop in the thread if you feel
like a warrior)

As a sidenode about inotify, there's another issue related to the
"outstanding file handles/ what-nots issue": by default, the number of
watches allowed per-user by the kernel is pretty low, that mean we might
have to choose which file we want to watch.

Anyway, to get back on our issues there are different other designs
available:
- We can have a separate state store in a 'singleton', with a weak link
between the item and the state store. The state store will handle expiring
states. When someone decides to implement inotify or stuff like that, it'll
be able to expand the state store with state manager modules, which would
subscribe to certain type of state and add state specific management code
running in its own thread. For example, when someone push a 'file state' to
the state store, the inotify state manager module will register an inotify
watch.
- Much simpler than the previous item, we can have something much like the
art fetcher. When the file.c access discover it's an directory, it pushes
the input_item and a _separate_ state object (basically the fd in our case)
and the browser will take this from it's thread and do its job. The issue
here is that we'll have to lock the item or something if we don't want to
have race conditions resulting in the playlist skipping to the next item
while the item is to be browsed
- Add your suggestions here


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

Ok.


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


If even you needs to speculate on this, there's no solution then. Does it
mean we should try and see how it reacts on the users computers, like in
the kernel ? I like that :-)


>
>
> --
> Rémi Denis-Courmont
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20140527/691c9668/attachment.html>