From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31186 invoked by alias); 18 Oct 2008 09:34:17 -0000 Received: (qmail 31178 invoked by uid 22791); 18 Oct 2008 09:34:17 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout3.012.net.il (HELO mtaout3.012.net.il) (84.95.2.7) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 18 Oct 2008 09:33:37 +0000 Received: from HOME-C4E4A596F7 ([77.126.98.197]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K8X00E6OHA4ROH3@i_mtaout3.012.net.il> for gdb-patches@sourceware.org; Sat, 18 Oct 2008 11:34:52 +0200 (IST) Date: Sat, 18 Oct 2008 09:34:00 -0000 From: Eli Zaretskii Subject: Re: generic `struct serial' interface pipe for remote non-stop In-reply-to: <200810172154.50092.pedro@codesourcery.com> X-012-Sender: halo1@inter.net.il To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: References: <200810170034.50863.pedro@codesourcery.com> <200810172154.50092.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2008-10/txt/msg00464.txt.bz2 > From: Pedro Alves > Date: Fri, 17 Oct 2008 21:54:49 +0100 > > - Since async signal handlers are always checked before polling the > file descriptors, I can easily starve the file descriptor based > sources. E.g., if I place several threads displace stepping a > breakpoint, forcing continuous remote traffic, the CLI becomes very, > very unresponsive, unusable really. This is because stdin itself > is registered as a monitored (via select/poll) file descriptor. > > To solve this, I adjusted the event loop to give equal priority to > all event-sources (timers, async signal handlers, monitored file > descriptors). The async signal handling was changed to instead > of immediatelly calling the associated callback, it installs an > event in the "ready" queue, just like the file-descriptor and > timer based sources. I then make sure that I poll each of the > possible event sources once (select/poll with timeout 0 too). If > if no event is found ready, then, we go blocking waiting for one > in select/poll. > > I can sucessfully debug a non-stop linux gdbserver from both > a linux host and a Windows (mingw32) host with this. > > The remote.c changes below apply on top of the non-stop support > patch I sent yesterday, and it's what I used to test, shown here > so you could see what was required that change, in case you're > curious about it. > > Do you think it is a better alternative? Yes, this is much better, IMO. Thanks.