From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alexander.turenko@tarantool.org>
Received: from smtp48.i.mail.ru (smtp48.i.mail.ru [94.100.177.108])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 41FFE469719
 for <tarantool-patches@dev.tarantool.org>;
 Wed,  4 Mar 2020 02:20:52 +0300 (MSK)
Date: Wed, 4 Mar 2020 02:20:49 +0300
From: Alexander Turenko <alexander.turenko@tarantool.org>
Message-ID: <20200303232049.fesmbz5axgixhc5e@tkn_work_nb>
References: <cover.1579605136.git.sergepetrenko@tarantool.org>
 <853c32f414c954d38b2621afc7babd57a6e031c4.1579605136.git.sergepetrenko@tarantool.org>
 <20200208194255.biakpjlbw3eh3qld@tkn_work_nb>
 <94B97C48-7273-418B-B404-CC714348254A@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <94B97C48-7273-418B-B404-CC714348254A@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH v2 1/2] build: link bundled libcurl
	with c-ares
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Serge Petrenko <sergepetrenko@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

> > 8 февр. 2020 г., в 22:42, Alexander Turenko <alexander.turenko@tarantool.org> написал(а):
> > 
> > I mostly okay with the patch, but expect several actions like filing
> > some issues against c-ares and curl and minor tweaks of the patch.
> > 
> > Re blocking in threaded resolver
> > --------------------------------
> > 
> > Let's file an issue to curl, because it is inappropriate to block an
> > application that expect libcurl to give a control if something would
> > block. An error like 'DNS resolver thread pool is exhausted' is better,
> > because it can be handled on an application side somehow:
> > 
> > * do other work / be responsible until free resolver threads will be
> >  available;
> > * give a user an error for further requests;
> > * dynamically increase threads count (automatically or upon a user
> >  request).
> 
> There already exist 2 issues: [1] - closed by a bot, unintentionally, I think.
> [2] - a duplicate of [1]. 

Thanks! Answered to the issue.

> [1]: https://github.com/curl/curl/issues/2975 <https://github.com/curl/curl/issues/2975>
> [2]: https://github.com/curl/curl/issues/4852 <https://github.com/curl/curl/issues/4852>