[vlc-devel] [PATCH 1/6] demux/adaptive: Downloader: faster response to request
Zhao Zhili
quinkblack at foxmail.com
Wed Sep 20 12:04:28 CEST 2017
Hi Hugo,
On 2017年09月20日 17:01, Hugo Beauzée-Luyssen wrote:
> Hi,
>
> On Wed, Sep 20, 2017, at 05:48 AM, Zhao Zhili wrote:
>> ---
>> modules/demux/adaptive/http/Downloader.cpp | 21 +++++++++++++++------
>> modules/demux/adaptive/http/Downloader.hpp | 4 +++-
>> 2 files changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/modules/demux/adaptive/http/Downloader.cpp
>> b/modules/demux/adaptive/http/Downloader.cpp
>> index ba81727..b2e64ef 100644
>> --- a/modules/demux/adaptive/http/Downloader.cpp
>> +++ b/modules/demux/adaptive/http/Downloader.cpp
>> @@ -28,12 +28,13 @@
>>
>> using namespace adaptive::http;
>>
>> -Downloader::Downloader()
>> +Downloader::Downloader() :
>> + thread_handle_valid(false),
>> + killed(false),
>> + pending_requests(0)
>> {
>> vlc_mutex_init(&lock);
>> vlc_cond_init(&waitcond);
>> - killed = false;
>> - thread_handle_valid = false;
>> }
>>
>> bool Downloader::start()
>> @@ -50,8 +51,8 @@ bool Downloader::start()
>>
>> Downloader::~Downloader()
>> {
>> + killed.store(true);
> Since the wait condition is always signaled/wait upon in a locked scope,
> I'm not sure this improves much
Call vlc_mutex_lock(&lock) and then set killed to true,
vlc_mutex_lock(&lock) will block until chunks.empty() is true.
98 while(1)
99 {
100 while(chunks.empty() && !killed)
101 vlc_cond_wait(&waitcond, &lock);
102
If we make killed an atomic variable and set it to true first, the big
while(1) in Downloader::Run() will break out more quickly since we don't
need to wait chunks.empty().
>> vlc_mutex_lock( &lock );
>> - killed = true;
>> vlc_cond_signal(&waitcond);
>> vlc_mutex_unlock( &lock );
>>
>> @@ -62,18 +63,23 @@ Downloader::~Downloader()
>> }
>> void Downloader::schedule(HTTPChunkBufferedSource *source)
>> {
>> + pending_requests.fetch_add(1);
>> vlc_mutex_lock(&lock);
>> source->hold();
>> chunks.push_back(source);
>> + pending_requests.fetch_sub(1);
>> vlc_cond_signal(&waitcond);
>> vlc_mutex_unlock(&lock);
>> }
>>
>> void Downloader::cancel(HTTPChunkBufferedSource *source)
>> {
>> + pending_requests.fetch_add(1);
>> vlc_mutex_lock(&lock);
>> source->release();
>> chunks.remove(source);
>> + pending_requests.fetch_sub(1);
>> + vlc_cond_signal(&waitcond);
>> vlc_mutex_unlock(&lock);
>> }
>>
>> @@ -97,10 +103,13 @@ void Downloader::Run()
>> vlc_mutex_lock(&lock);
>> while(1)
>> {
>> - while(chunks.empty() && !killed)
>> + while(chunks.empty() && killed.load() == false)
>> + vlc_cond_wait(&waitcond, &lock);
>> +
>> + while(pending_requests.load() > 0 && killed.load() == false)
> I'm not sure I understand the idea behind this second wait
It's the same idea as above, make Downloader::schedule() and
Downloader::cancel() acquire the lock more quickly.
>> vlc_cond_wait(&waitcond, &lock);
>>
>> - if(killed)
>> + if(killed.load())
>> break;
>>
>> if(!chunks.empty())
>> diff --git a/modules/demux/adaptive/http/Downloader.hpp
>> b/modules/demux/adaptive/http/Downloader.hpp
>> index 1d6cc57..ec76b3f 100644
>> --- a/modules/demux/adaptive/http/Downloader.hpp
>> +++ b/modules/demux/adaptive/http/Downloader.hpp
>> @@ -23,6 +23,7 @@
>> #include "Chunk.h"
>>
>> #include <vlc_common.h>
>> +#include <atomic>
>> #include <list>
>>
>> namespace adaptive
>> @@ -48,7 +49,8 @@ namespace adaptive
>> vlc_mutex_t lock;
>> vlc_cond_t waitcond;
>> bool thread_handle_valid;
>> - bool killed;
>> + std::atomic_bool killed;
>> + std::atomic_int pending_requests;
>> std::list<HTTPChunkBufferedSource *> chunks;
>> };
>>
>> --
>> 2.7.4
>>
> Regards,
>
More information about the vlc-devel
mailing list