[Mplayerplug-in-devel] Additions to playlist

[Alex E. <ale...@ya...>]

Hi Kevin,

It seems that DestroyStream adds the file to the playlist
without checking if it is in the playlist already. 

Is this something I broke, or was it always doing this?
(I really did not make any changes in that area). 

Best, 

Alex
 


--- Kevin DeKorte <kde...@ya...> wrote:
> Alex,
> 
> Ok, I have applied this patch, but have not tested it... 
> 
> Couple of things that should be noted
> 
> 1. JS_STATE_INITIALIZING
> 
> 	All the JS_STATE statics are the statics used in windows media
> player, I'm 
> not sure if we should "add" another state. Perhaps using "state"
> would be 
> better?
> 
> 2. Um.. can't think of anything else at the moment.. :)
> 
> Looks good from the parts I have looked at.
> 
> Kevin
> 
> On Saturday 06 March 2004 11:55 pm, Alex Eskin wrote:
> > Hi,
> >
> > I have a fairly large patch which implements lots more locking
> > (but still not everything needed). I hope you can apply it.
> > I did not do as much testing as I wanted (even though I did do
> > a bit). Still, I am sending it to you now or else we may have
> > a really horrible time merging.
> >
> > If you apply this patch, I have also written a file
> (locking_rules.txt)
> > which describes the new locking rules. At the moment I
> > violate (slightly) my own rule (3), but it is only a becomes a
> > factor when the control pipe is full. The next patch will
> > implement non-blocking IO on the control pipe, which will cure
> > the problem.
> >
> > The patch introduces a new mutex (control_mutex).
> > I have concentrated only on locking, and tried not to change the
> > logic as much as possible.
> >
> > It is supposed to do the following:
> >
> > a)Remove gdk_threads_enter and gdk_threads_leave. They are not
> >   needed with g_idle_add.
> >
> > b) Remove logic for conditions that can no longer occur with the
> >    new pthreads code. Replaced the tests with asserts for now
> >    (so we can be sure these conditions don't occur).
> >
> > c)Fix a race where the thread was signalled immediately after it
> was
> >   started, and the signal was lost. (This race occured for sure,
> but
> >   it was mostly harmless).
> >
> > d) Fix the following race:
> >    main thread                                 player thread
> >
> >    if ( control != NULL ) {
> >                                                fclose(control);
> >                                                control == NULL;
> >        fwrite(control, command)
> >
> >
> > (this would cause a crash).
> >
> > e) Fix various races of the following form:
> >    main thread                               player thread
> >
> >     if (js_state == something) {
> >                                               js_state =
> someting_else
> >
> >       /*
> > 	   do stuff assuming
> >            js_state == something
> >        */
> > f) when the player thread was advancing to the next item in the
> > playlist, it was not taking playlist_lock. This could have lead to
> > crashes.
> >
> > Note: I got a function off the web called pthread_delay().
> > It is now at the beginning of plugin-threads.cpp, but
> > should probably go in a separate file.
> >
> >
> > Let me know what you think.
> >
> > Best,
> >
> > Alex
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Search - Find what you’re looking for faster
> > http://search.yahoo.com


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com