From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73775 invoked by alias); 25 Feb 2019 19:57:53 -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 73755 invoked by uid 89); 25 Feb 2019 19:57:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=gdbserver, H*f:sk:83sgwdn, adaptation, H*f:sk:87va19j X-HELO: gateway32.websitewelcome.com Received: from gateway32.websitewelcome.com (HELO gateway32.websitewelcome.com) (192.185.145.100) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Feb 2019 19:57:51 +0000 Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 51A97B34FA for ; Mon, 25 Feb 2019 13:57:50 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id yMNqg92Un90onyMNqgTxgN; Mon, 25 Feb 2019 13:57:50 -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=UJ03F3UhHEEK/jAxrF9pTP85bo0fGz5p06Jk5NF979Y=; b=S5LrAK5BnzaktUCvVgfTD7t5VE ryD0650LP5fTOT8jcdckQMZenoLPrYedJbNpzgtzN7IU5muVNVQ5cSy0ApMphg0SLvo2DW6H0K1kG OA18qtiYSOVayJlRL8Kf5OAy1; Received: from 75-166-72-210.hlrn.qwest.net ([75.166.72.210]:58494 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gyMNq-002JKD-1e; Mon, 25 Feb 2019 13:57:50 -0600 From: Tom Tromey To: Eli Zaretskii Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC 00/17] Merge event loop implementations References: <20190224165153.5062-1-tom@tromey.com> <83sgwdnm6r.fsf@gnu.org> <87va19jdy4.fsf@tromey.com> <83r2bxnkrb.fsf@gnu.org> Date: Mon, 25 Feb 2019 19:57:00 -0000 In-Reply-To: <83r2bxnkrb.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 24 Feb 2019 19:45:12 +0200") Message-ID: <87imx7vdxe.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-02/txt/msg00416.txt.bz2 >>>>> "Eli" == Eli Zaretskii writes: Eli> I'm sorry, I cannot help you with this dilemma. Not unless someone Eli> describes in more detail the actual needs of both GDB and gdbserver Eli> for which they call 'select'. I myself don't know enough about the Eli> internals to give any advice. No problem. For gdb, this series doesn't actually change anything. So, it's really only gdbserver that we have to be concerned with. By my reading of the code, gdbserver on Windows can call select with just two file descriptors: one that is a socket that is being 'listen'd to, and another which is the result of 'accept'. (On other hosts, gdbserver can also read from stdin, but this is explicitly rejected on Windows.) Eli> The long-term goal is probably to import the Gnulib implementation of Eli> 'select', which AFAIR supports any kind of descriptors. But that Eli> would need some adaptation work. Do you know offhand what is needed? I didn't know that gnulib had this... this does seem like a good way to go if possible. Tom