From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104894 invoked by alias); 24 Oct 2018 18:08:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 104173 invoked by uid 89); 24 Oct 2018 18:08:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Oct 2018 18:08:20 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 28663300C778; Wed, 24 Oct 2018 18:08:19 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 83CF260C46; Wed, 24 Oct 2018 18:08:18 +0000 (UTC) Subject: Re: [PATCH v2] Release the GIL while running a gdb command or expression To: Tom Tromey References: <20181010202233.17985-1-tom@tromey.com> <6c7d1b6d-2d7a-dcaf-8d20-615bfb474af9@redhat.com> <871s8qcab9.fsf@tromey.com> <4aa9c215-9b86-40f9-37e9-d96121e80736@redhat.com> <87woqhbmh6.fsf@tromey.com> <87sh15bm71.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <8b981b27-1e15-31d8-0342-492700468ecf@redhat.com> Date: Wed, 24 Oct 2018 18:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87sh15bm71.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-10/txt/msg00558.txt.bz2 On 10/16/2018 10:45 PM, Tom Tromey wrote: >>>>>> "Tom" == Tom Tromey writes: > > Tom> Also the Python code is calling print on a gdb stream in a background > Tom> thread, which is a no-no. > > If you ignore this then I have a version that works. Racy in theory but > maybe not in practice. We have plenty of tests that shouldn't be racy in theory but are in practice. So I'd instead assume that in practice someone will definitely run into the race. Do we really need to rely on printing to check this? If the the gdb.execute command can run some more python code, then we could try using a couple python mutexes for proving the non-main thread runs. So the non-main thread would wait on mutex1 which starts owned by the main thread. The main thread unlocks mutex1 and blocks on mutex2, waiting for the non-main thread to release it. The non-main thread should now run, and is now the mutex1 owner. It now releases mutex2. The main thread now unblocks, and the test succeeds. If we don't release the GIL properly, then the non-main thread won't run, and the testcase times out. Or something along those lines. Thanks, Pedro Alves