[vlc-devel] Re: vlc: svn commit r20432 (pdherbemont)

[Damien Fouilleul]

Pierre d'Herbemont wrote:
>
> On 7 juin 07, at 16:52, Rémi Denis-Courmont wrote:
>
>> Le jeudi 7 juin 2007, Pierre d'Herbemont a écrit :
>>> About polling I am not convinced that it is a good solution. Most of
>>> the time you end up in wasting CPU time. (especially when polling for
>>> an event that never occurs). Thus I really think it is fair to
>>> consider a position event.
>>
>> Polling is bad... when you cannot predict when the event occurs.
>>
>> Performance position is likely enough to advance visibly every second
>> that it may be reasonable to poll once or twice per sec, rather than
>> use an event. Note that the input/demux stuff will cause a lot more
>> wakeups than 1 or 2/sec while performing in any case, so the battery
>> drain is not very significant.
>
> Well, it sounds reasonable, but I don't see why using an event would 
> be bad. It really looks sounder. And especially in the case of libvlc 
> where this API is made available to third-parties. Let us save the 
> work they'll have when setting up their polling thread, and prevent 
> them from doing bad thing as much as we can.
>
> Pierre.
i agree with Remi, you should only need events to cater for the 
unexpected. Position change is an expected behaviour, only other events 
such input buffer underflow/overflow, stop/pause, fast forward, etc.. 
would affect that behaviour and i'd rather get events for these rather 
than try to guess them from analyzing the position behaviour.
Regarding CPU wasting, polling is usually the best option as you can 
schedule when you want to poll, which is usually in idle time within an 
event loop, etc...
Obviously, there are situations when you are better off with events, 
which is usually, as i said before, when you are dealing with unexpected 
changes. Because if you want to detect them through polling you need to 
poll at the worse case frequency, and in the case where it is a fairly 
high one, then you really start to waste cpu time and sometimes you are 
not even guaranteed to catch the change you are monitoring.

Please note that events forces the consumer to process them at 
unexpected time, and you can't always assume that a consumer is always 
capable of processing events at the same rate or faster than the 
publisher is pushing them, therefore the publisher needs to implement 
smart strategies such as dropping less important events, use collation, 
etc... whenever the event queue is full in order to avoid stalls, are 
you willing to implement that as well ?

I'm not trying to scare you off, but i know though experience, that 
generating events is not always the best solution for every situation, 
and can have perverse effects if badly used.

Damien.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html