From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22673 invoked by alias); 20 Mar 2008 17:00:02 -0000 Received: (qmail 22518 invoked by uid 22791); 20 Mar 2008 17:00:01 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Mar 2008 16:59:42 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 485EB98278; Thu, 20 Mar 2008 16:59:40 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 2571D98149; Thu, 20 Mar 2008 16:59:40 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JcO79-0006ic-5p; Thu, 20 Mar 2008 12:59:39 -0400 Date: Thu, 20 Mar 2008 17:01:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org, gdb@sources.redhat.com Subject: Re: Async function calls Message-ID: <20080320165939.GA25765@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org, gdb@sources.redhat.com References: <200803201044.47454.vladimir@codesourcery.com> <20080320121019.GA6677@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00175.txt.bz2 On Thu, Mar 20, 2008 at 03:21:44PM +0300, Vladimir Prus wrote: > Will it help? Say, we do: > > print foo() > > then to do it async way, we have to do the function call, and then > 'print' should get back to action and print the value. Right now, > print_command has no continuations, so we'll have to add it. > And likewise, it seems that every command that can call a function > will have to be converted to use continuation. You're right, it wouldn't help unless we did this all the way from the top: centralized parsing for commands before we dispatched to the command functions, that knew what was an expression. And I don't think that's a practical idea. -- Daniel Jacobowitz CodeSourcery From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22966 invoked by alias); 20 Mar 2008 17:00:05 -0000 Received: (qmail 22746 invoked by uid 22791); 20 Mar 2008 17:00:05 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Mar 2008 16:59:42 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 485EB98278; Thu, 20 Mar 2008 16:59:40 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 2571D98149; Thu, 20 Mar 2008 16:59:40 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JcO79-0006ic-5p; Thu, 20 Mar 2008 12:59:39 -0400 Date: Thu, 20 Mar 2008 17:24:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org, gdb@sources.redhat.com Subject: Re: Async function calls Message-ID: <20080320165939.GA25765@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org, gdb@sources.redhat.com References: <200803201044.47454.vladimir@codesourcery.com> <20080320121019.GA6677@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00176.txt.bz2 Message-ID: <20080320172400.K9NvvZfhK-o9fmHaSzGM3oJvc2oJzUfeS4ZxdkPaAss@z> On Thu, Mar 20, 2008 at 03:21:44PM +0300, Vladimir Prus wrote: > Will it help? Say, we do: > > print foo() > > then to do it async way, we have to do the function call, and then > 'print' should get back to action and print the value. Right now, > print_command has no continuations, so we'll have to add it. > And likewise, it seems that every command that can call a function > will have to be converted to use continuation. You're right, it wouldn't help unless we did this all the way from the top: centralized parsing for commands before we dispatched to the command functions, that knew what was an expression. And I don't think that's a practical idea. -- Daniel Jacobowitz CodeSourcery