<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 27, 2014 at 10:20 AM, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Currently, i dont pass the fd from the access to the browser.<br>
</blockquote>
<br>
I consider that a design problem. That's exactly my point.</blockquote><div><br></div><div>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)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On the other hand, for remote browsable node, sharing a state would<br>
actually be pretty nice to speed things up. <br>
</blockquote>
<br></div>
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).<br></blockquote>
<div><br></div><div>What is toctou ? An island from "pirates of the caribbean" ? (Yes, this is a joke)</div><div>We might want to explain that to playlist (pls, m3u) file writer. Don't use m3u, it has a TOCTOU issue :) (Another stupid joke)<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
A solution could be adding a vlc_object_t state to the input_item_t in<br></div>
order to store a state, its origin and handling its cleanup.<br>
</blockquote>
<br>
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.<br>
</blockquote><div><br></div><div>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)</div>
<div><br></div><div>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.<br>
</div><div><br></div><div>Anyway, to get back on our issues there are different other designs available:</div><div>- 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.</div>
<div>- 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</div>
<div>- Add your suggestions here </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>Ok.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
Im not sure i realize all the implications of it. But i kinda feel the<br>
event management mechanism and the gc should allow for implementing it<br>
? I mean, the worst case is when an item is currently being played and<br>
it gets deleted but in that case, either the system will wait for the<br>
last fd to be closed to actually delete the item or the access will<br></div>
fail and well be able to release the item, no ?<br>
</blockquote>
<br>
I can't speculate on that.</blockquote><div><br></div><div>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 :-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
-- <br>
Rémi Denis-Courmont<br>
______________________________<u></u>_________________<br>
vlc-devel mailing list<br>
To unsubscribe or modify your subscription options:<br>
<a href="https://mailman.videolan.org/listinfo/vlc-devel" target="_blank">https://mailman.videolan.org/<u></u>listinfo/vlc-devel</a><br>
</div></div></blockquote></div><br></div></div>