[vlc-devel] [PATCH] -- media_list

[brezhoneg1]

-----Message d'origine-----
De : Rémi Denis-Courmont [mailto:rem at videolan.org] 
Envoyé : dimanche 7 décembre 2008 20:42
À : vlc-devel at videolan.org
Cc : brezhoneg1
Objet : [Bulk] Re: [vlc-devel] [PATCH] -- media_list

Le vendredi 5 décembre 2008 15:31:08 brezhoneg1, vous avez écrit :
> This patch corrects several bugs that prevent media_list (libvlc
api) to
> work at all (transition from one item to the next).
>
> I'm re-sending it just in case it was forgotten (and before other
> changes occur that makes it un-applicable)

I don't see the point of checking for NULLity when clearing an
exception. 
IMHO, it would make more sense to assert against that stupid case.


Answer:
  Checking for ( p_exception != NULL ) was an easy way to work out a
crash that did occur without too many changes.
  Several parts of libvlc (internals) set p_exception to NULL. Then
p_exception is passed from a function to another. At some point,
exception is cleared without checking if the pointer is NULL or not. And
crash occurs.
--------


More importantly, you cannot create a thread and forget about it. That
would 
be a major leak, especially w.r.t. the address space. Any thread MUST be

joined somewhere and preferrably as early as possible.


Answer:
I do agree vlc_clone is a bad solution. I thought of pthread_detach but
it seems no vlc wrapper exists for it.
Let me explain the issue and you may help me find another way to do it.

A Media_list automates playing one media after the other. The way for
media_list to know a media reached the end is through events and
callbacks run by the input thread. The action to carry out once the end
is reached is to clean up the current input thread and start a new one.
That leads to the input thread waiting for its own death (vlc_join
itself). 
Media_list doesn't have its own thread. Those are functions run by the
end-user (the libvlc api C developer) who doesn't have a clue what the
internals of media_list are. At some point, a new thread seems the only
way to avoid the deadlock issue.

Any idea how to tackle this situation ?

------------


Sorry, but this patch looks pretty bad to me.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary