<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 26, 2014 at 1:13 PM, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> wrote:<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">Le 2014-05-26 18:53, Julien 'Lta' BALLET a écrit :<div class="">
<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">
I do not assume directories are serializable. The browse module<br>
receive a stream_t when you are trying to access an API over http, but<br>
not when you a trying to browse a folder.<br>
</blockquote>
<br></div>
But that's exactly the problem. How do you pass the file descriptor from the access to the whatever-browser after (only after) fstat() tells you it is a directory? This is not serializable, so it cannot be passed via the input_item_t.</blockquote>
<div><br></div><div>Currently, i don't pass the fd from the access to the browser. Considering the number of fd that are open during browsing, i thought that one more or one less wasn't a critical matter. Right now, the access just marks the item as browsable and exits, the browser will re-open the fd.<br>
</div><div><br></div><div>On the other hand, for remote browsable node, sharing a state would actually be pretty nice to speed things up. </div><div>A solution could be adding a vlc_object_t state to the input_item_t in order to store a state, it's origin and handling its cleanup. We can even make the input_item_t a vlc_object_t, as vlc_object_t have been simplified a lot since the time input_item were created (at the beginning of times). Do you think one of this is a proper approach to the issue ?</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>
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.</blockquote><div><br></div><div>
I never wanted to serialize anything. I'm trying to _remove_ xpsf serialization :)</div><div><br></div><div>This asynchronous inotify thread seems to me like a whole other issue. I'm 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 we'll be able to release the item, no ?</div>
<div><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"><div class="">
<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">
In that case, the module has<br>
to assume the access role (access_browser, much like access_demux).<br>
The access_browse is likely to be part of the same .so that the<br>
regular access<br>
</blockquote>
<br></div>
Using the same shared object solves sharing code, not sharing state.</blockquote><div><br></div><div>Indeed. </div></div></div></div>