From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93720 invoked by alias); 30 May 2019 13:12:46 -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 93712 invoked by uid 89); 30 May 2019 13:12:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=principle X-HELO: mail-wm1-f65.google.com Received: from mail-wm1-f65.google.com (HELO mail-wm1-f65.google.com) (209.85.128.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 May 2019 13:12:45 +0000 Received: by mail-wm1-f65.google.com with SMTP id c6so884177wml.0 for ; Thu, 30 May 2019 06:12:44 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4eeb:42ff:feef:f164? ([2001:8a0:f913:f700:4eeb:42ff:feef:f164]) by smtp.gmail.com with ESMTPSA id c11sm1764282wrs.97.2019.05.30.06.12.41 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 30 May 2019 06:12:41 -0700 (PDT) Subject: Re: [PATCH v3 5/8] Introduce run_on_main_thread To: Tom Tromey , gdb-patches@sourceware.org References: <20190529212916.23721-1-tom@tromey.com> <20190529212916.23721-6-tom@tromey.com> From: Pedro Alves Message-ID: <9f9ea56d-349f-dc19-6201-9241fee71e49@redhat.com> Date: Thu, 30 May 2019 13:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190529212916.23721-6-tom@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00684.txt.bz2 On 5/29/19 10:29 PM, Tom Tromey wrote: > This introduces a way for a callback to be run on the main thread. Can Python's gdb.post_event be built on top of this? It would fix that nasty "atomically enough" race in gdbpy_run_events, I guess. > > gdb/ChangeLog > 2019-05-29 Tom Tromey > > * ser-event.h (run_on_main_thread): Declare. > * ser-event.c (runnable_event, runnables, runnable_mutex): New > globals. > (run_events, run_on_main_thread, _initialize_ser_event): New > functions. > --- > gdb/ChangeLog | 8 ++++++ > gdb/ser-event.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++ > gdb/ser-event.h | 6 +++++ > 3 files changed, 83 insertions(+) > > diff --git a/gdb/ser-event.c b/gdb/ser-event.c > index d3956346246..4870433b287 100644 > --- a/gdb/ser-event.c > +++ b/gdb/ser-event.c > @@ -20,6 +20,10 @@ > #include "ser-event.h" > #include "serial.h" > #include "common/filestuff.h" > +#if CXX_STD_THREAD > +#include > +#endif > +#include "event-loop.h" > > /* On POSIX hosts, a serial_event is basically an abstraction for the > classical self-pipe trick. > @@ -217,3 +221,68 @@ serial_event_clear (struct serial_event *event) > ResetEvent (state->event); > #endif > } > + > + > + > +/* The serial event used when posting runnables. */ > + > +static struct serial_event *runnable_event; > + > +/* Runnables that have been posted. */ > + > +static std::vector> runnables; > + > +#if CXX_STD_THREAD > + > +/* Mutex to hold when handling runnable_event or runnables. */ > + > +static std::mutex runnable_mutex; > + > +#endif > + > +/* Run all the queued runnables. */ > + > +static void > +run_events (int error, gdb_client_data client_data) > +{ > + std::vector> local; > + > + /* Hold the lock while changing the globals, but not while running > + the runnables. */ > + { > +#if CXX_STD_THREAD > + std::lock_guard lock (runnable_mutex); > +#endif > + > + /* Clear the event fd. Do this before flushing the events list, > + so that any new event post afterwards is sure to re-awaken the > + event loop. */ > + serial_event_clear (runnable_event); > + > + /* Move the vector in case running a runnable pushes a new > + runnable. */ > + std::swap (local, runnables); > + } > + > + for (auto &item : local) > + item (); I'd think this should swallow errors when calling each item, instead of letting an exception escape and discard all other items, since each item call should be in principle logically unrelated? Maybe we could unit test this code. Thanks, Pedro Alves