From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19272 invoked by alias); 17 Oct 2008 10:22:28 -0000 Received: (qmail 19261 invoked by uid 22791); 17 Oct 2008 10:22:27 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout6.012.net.il (HELO mtaout6.012.net.il) (84.95.2.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Oct 2008 10:21:48 +0000 Received: from HOME-C4E4A596F7 ([77.127.24.3]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K8V005WUOU4LV40@i-mtaout6.012.net.il> for gdb-patches@sourceware.org; Fri, 17 Oct 2008 12:22:52 +0200 (IST) Date: Fri, 17 Oct 2008 10:22:00 -0000 From: Eli Zaretskii Subject: Re: generic `struct serial' interface pipe for remote non-stop In-reply-to: <200810170034.50863.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> 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/msg00426.txt.bz2 > From: Pedro Alves > Date: Fri, 17 Oct 2008 00:34:50 +0100 > > For non-stop mode, however, I'll need two other event sources registered in > the event loop, that are independant of the remote communication, as you'll > see in the patch I'll post soon. The easiest way to get us a select'able > file descriptor with the properties we want, is a pipe. We register the > read end in the event loop, and write something to the write end whenever > we have something interesting to tell the core about. Forgive me, especially if I talk out of ignorance or misunderstanding, but isn't this a horrible design? We need to communicate to the event loop that some event happened, and we do that by opening a pipe between one part of GDB and another, and talk to ourselves via that pipe? Can't we instead register with the event loop some callback that would tell the loop that an event arrived? Heck, even raise-ing a signal would be better. > Now, the problem with remote.c, is that it is built on all hosts, and it > happens that on Windows, the file descriptors returned from `_pipe' > are not waitable on. Right, because the above design is also horribly non-portable. > For go32/djgpp or for unix hosts that don't have socketpair, I > just bail out with ENOSYS. Does that mean that some feature that could have worked for DJGPP with a different design, will now be broken by design? If so, I'd like us to look for alternatives.