From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49690 invoked by alias); 4 Nov 2018 15:54:07 -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 49678 invoked by uid 89); 4 Nov 2018 15:54:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=theory, owned, practice X-HELO: gateway36.websitewelcome.com Received: from gateway36.websitewelcome.com (HELO gateway36.websitewelcome.com) (192.185.200.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 04 Nov 2018 15:54:05 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway36.websitewelcome.com (Postfix) with ESMTP id A23AD400CB0B4 for ; Sun, 4 Nov 2018 09:02:12 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id JKiygWO1PkBj6JKiygXCWE; Sun, 04 Nov 2018 09:54:04 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ELBeIxrTHKLKK1VVAma41AeFk+DQjq7SNCDm1ifTvPc=; b=oey1n/+gC84lEkTpC2SW2KdjLV TBOZ2vP7xYZ0kHNDL0t/nzz1fxoiib+wWmGhS190WnjjJrcBkWYvkXuVlIBnMqqKugwcrLe86z0Gc U/OEusTIT50e/ncDfxFYEoo/E; Received: from 97-122-190-66.hlrn.qwest.net ([97.122.190.66]:50098 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gJKix-000qG5-Tu; Sun, 04 Nov 2018 09:54:04 -0600 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH v2] Release the GIL while running a gdb command or expression 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> <8b981b27-1e15-31d8-0342-492700468ecf@redhat.com> Date: Sun, 04 Nov 2018 15:54:00 -0000 In-Reply-To: <8b981b27-1e15-31d8-0342-492700468ecf@redhat.com> (Pedro Alves's message of "Wed, 24 Oct 2018 19:08:17 +0100") Message-ID: <8736sg4z50.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-11/txt/msg00033.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Tom> If you ignore this then I have a version that works. Racy in theory but Tom> maybe not in practice. Pedro> We have plenty of tests that shouldn't be racy in theory but are Pedro> in practice. So I'd instead assume that in practice someone will Pedro> definitely run into the race. Pedro> Do we really need to rely on printing to check this? If the Pedro> the gdb.execute command can run some more python code, then Pedro> we could try using a couple python mutexes for proving the Pedro> non-main thread runs. Pedro> So the non-main thread would wait on mutex1 which starts owned Pedro> by the main thread. The main thread unlocks mutex1 and blocks Pedro> on mutex2, waiting for the non-main thread to release it. Pedro> The non-main thread should now run, and is now the mutex1 owner. Pedro> It now releases mutex2. The main thread now unblocks, and the Pedro> test succeeds. If we don't release the GIL properly, then Pedro> the non-main thread won't run, and the testcase times out. It took me a little experimenting to understand why this can't work. The main thread can't run any Python code at all. If it does run Python code, then Python might release the GIL. And, when dealing with thread primitives like mutexes or whatnot, it certainly will. However, if the main thread does release the GIL, then that invalidates the test -- since we are trying to test that the GIL is released under ordinary circumstances. I'm back to not seeing a way to test this. Tom