[vlc-devel] Problem using libvlc

[Laurent Aimar]

Hi,

On Sat, May 23, 2009, Pierre d'Herbemont wrote:
> On Fri, May 22, 2009 at 3:39 PM, Laurent Aimar <fenrir at via.ecp.fr> wrote:
> > On Fri, May 22, 2009, Pierre d'Herbemont wrote:
> >> >> I may end up fixing it. There are some vlc core limitation that needs
> >> >> to be addressed first.
> >> >  What are the limitations you have in mind ?
> >>
> >> Variables callback can't be removed from within a callback. This is
> >> doable but requires some careful work. (We have that for the events.c
> >> stuff - which has its own limitation though)
> >  At least for input_thread_t you MUST have a thread dedicated to manage
> > it, so it should not be a problem. (if you don't you will end up having
> > a lot of deadlock problems and you will perturb too much the input if
> > any time is used inside the callback for intf-event).
> 
> Well, I see what you mean, but what is the rationale behind this?
 You cannot take any measurable time inside the event callback because
you will break the input thread timing. There is no way around it except
using a thread to delay the action.

> So the inputthread would be not re-entrant. Not being reentrant here,
> basically prevents fine grained operation that a client may want to
> do, such as pausing as soon as first frame get received (just to be
> more specific... I should probably figure out a better use case :) ).
 No reentrant does not mean that what you asked cannot be done. It is
really easy to add such support in the input at low code cost.

> In the end, it is a nice idea to have the input thread re-entrant. It
 It is also most of the time very complicated to achieve in a *simple*
way. Everywhere an event can be issued, you have to care about the current
locks/resources taken and be carefull everytime you do even a tiny change.
You also have to ensure state coherency which can be very hard to do.
 

> allows to do cool thing from a client side,
 I don't see any that need it.
> and saves an event > dispatcher thread that the client might not require.
 That would be the only thing that can have an advantage. Except that I don't
think the complexity involved to remove/maintain it is worth the pain.

> And this removes
> all the glue code needed for synchronization and stuff.
 And would add more code to delay event when a ressource is held, and add more
burdden on the maintainer.

> Though, I think that the input_thread_t code is reentrant on most event already.
 Probably, yes. But I don't want to ensure it on all events nor maintain a list
of safe ones.

> > (But there is currently a problem bypassing the PL, all playlist parsing
> > demuxer/access use playlist_t directly :(
> 
> I am not sure about that, I removed most of the dependency from
> SD/playlist demuxer. They should be using an input_item_t interface.
> That allows you to get the media contained in a playlist file with
> libvlc, or the SD list, without using the playlist.
 Becarefull that an event from an item_t can be issue while an input resources/lock
is held, so you need to delay actions against an input here too.

-- 
fenrir