From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31524 invoked by alias); 20 Mar 2008 07:45:12 -0000 Received: (qmail 31513 invoked by uid 22791); 20 Mar 2008 07:45:11 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Mar 2008 07:44:49 +0000 Received: (qmail 12084 invoked from network); 20 Mar 2008 07:44:47 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Mar 2008 07:44:47 -0000 From: Vladimir Prus To: gdb@sources.redhat.com Subject: Async function calls Date: Thu, 20 Mar 2008 12:10:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803201044.47454.vladimir@codesourcery.com> 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/msg00171.txt.bz2 Right now, most commands that start inferior have provisions for async execution -- if a command has to do something after the inferior is stopped, it adds a 'continuation' which is executed. The notable exception is the code for calling inferior functions. We cannot use the continuation trick directly, because function call is done in the middle of expression evaluation, in general, so we should return the called function's return value. We cannot return to event loop, then handle inferior stop event, and then continue evaluating the expression. Then, the only way to make function calls async would be run inner event loop inside call_function_by_hand. This is honestly scary. Worst case, user can go as far as to start a different program, possibly invalidating lots of data that callers of call_function_by_hand will try to use. And in general, if we wait long enough, all of program state can change. Of course, we can "audit" all the code involved in evaluating an expression, figure which commands or events can adversely affect that code, and then disallow those commands while inferior call is in progress, but that sounds like a huge amount of work. Maybe, somebody have bright ideas? Thanks, Volodya