From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89188 invoked by alias); 20 Mar 2019 17:39:11 -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 89177 invoked by uid 89); 20 Mar 2019 17:39:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HContent-type:plain, HContent-type:charset, HContent-type:text X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Mar 2019 17:39:09 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6fB9-0002Hr-3z; Wed, 20 Mar 2019 13:39:05 -0400 Received: from [176.228.60.248] (port=3020 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h6fB7-0000D9-3h; Wed, 20 Mar 2019 13:39:02 -0400 Date: Wed, 20 Mar 2019 17:39:00 -0000 Message-Id: <83o965sax9.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: tom@tromey.com, gdb-patches@sourceware.org In-reply-to: <3fc20d2b-5a49-928a-b474-f812f43a2c12@redhat.com> (message from Pedro Alves on Wed, 20 Mar 2019 15:46:47 +0000) Subject: Re: [PATCH] Readline: Cleanup some warnings References: <20190130085716.75179-1-alan.hayward@arm.com> <20190131075907.GA313@adacore.com> <3463805B-A8BF-4C20-ACE3-C21AE3F7DB62@arm.com> <20190201080533.GA31043@adacore.com> <877eejvfoq.fsf@tromey.com> <1549047248.2630.7.camel@skynet.be> <310315f8-62ab-2eff-042f-9f2ae9de07da@redhat.com> <87wokxtnlt.fsf@tromey.com> <83h8c1wdr5.fsf@gnu.org> <87imwex333.fsf@tromey.com> <711b6636-b02c-edb2-308d-5fddbf4c33a9@redhat.com> <83ftritydv.fsf@gnu.org> <3fc20d2b-5a49-928a-b474-f812f43a2c12@redhat.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00435.txt.bz2 > Cc: tom@tromey.com, gdb-patches@sourceware.org > From: Pedro Alves > Date: Wed, 20 Mar 2019 15:46:47 +0000 > > > I agree: the right solution would be for the Readline's SIGINT handler > > to stop the main thread (e.g., by using SuspendThread). > > I don't sure how having the SIGINT handler stop the main thread is > a 100% correct solution. By the time you stop it, the main thread can well > be already running readline code, halfway through updating some data > structure, even if the mainline code disabled SIGINT temporarily, > with _rl_block_sigint, because by the time the mainline code calls > _rl_block_sigint, the SIGINT thread may have already have been spawned. How is this different from what happens on Posix platforms, where the SIGINT handler can be invoked at any moment, while Readline might be doing anything at all? > Also, you're not ever supposed to use SuspendThread for synchronization, I > believe. We are also not supposed to mix CRT and Win32 API functions, but we do that all the time. > MSDN at says: > > "This function is primarily designed for use by debuggers. It is not intended > to be used for thread synchronization." > > And here it says: > > "The Suspend­Thread function tells the scheduler to suspend the thread > but does not wait for an acknowledgment from the scheduler that the suspension > has actually occurred." GNU Make does it for many years, and I have yet to hear a single complaint about that part. > I think a mutex/lock for synchronization would be a better solution within > readline. Make all mainline readline entry points grab a mutex on entry > and release it on exit. Likewise, make the readline signal handler > hold a mutex around any code that is unsafe to run in parallel > with mainline code. That's fine with me, but is much more complex, and will probably slow down the code. I won't object if you want to do it that way, though. > I'm not sure whether readline still installs its own signal handler > internally in other situations, but it'd be worth it to check that. > Maybe we never run any readline signal handler on Windows at all > nowadays with recent readlines, which would simplify things for us, > rendering the gdb hack in question obsolete. Maybe we should bring Chet into this discussion.