From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lvasiliev@tarantool.org>
Received: from smtp47.i.mail.ru (smtp47.i.mail.ru [94.100.177.107])
 (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 E331D4696C3
 for <tarantool-patches@dev.tarantool.org>;
 Wed, 22 Apr 2020 17:52:19 +0300 (MSK)
References: <41a1decbbad25ee4b080052e64f65d1c4206c426.1587490798.git.lvasiliev@tarantool.org>
 <20200422142046.GA3072@uranus>
From: lvasiliev <lvasiliev@tarantool.org>
Message-ID: <1ba0a66e-e252-99d7-5eb9-b5d5fbe8f95e@tarantool.org>
Date: Wed, 22 Apr 2020 17:52:18 +0300
MIME-Version: 1.0
In-Reply-To: <20200422142046.GA3072@uranus>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [Tarantool-patches] [PATCH] Add a check whether glibc is used
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: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: tarantool-patches@dev.tarantool.org

Hi!

On 22.04.2020 17:20, Cyrill Gorcunov wrote:
> On Tue, Apr 21, 2020 at 08:44:57PM +0300, Leonid Vasiliev wrote:
>> The cbus hang test uses glibc pthread mutex implementation details.
>> Therefore, it should not compile in case of using another library.
>> ---
>> Now the compilation for alpine 3.5 is broken.
> 
> Wait, I don't understand. We'are using tt_pthread in core code
> as well. How tarantool compiles on it then?
The cbus hang test uses glibc pthread mutex implementation details
(internal fields of mutex).
Comment from code of cbus_hang test:
" We want to cancel canceled thread in the moment of cpipe_flush_cb
  will be processing.
  A Linux specific dirty hack will be used for reproduce the bug.
  We need to synchronize the main thread and the canceled worker thread.
  So, do it using the endpoint's mutex internal field(__data.__lock)."
"A Linux specific" - a glibc specific.

>