Async function calls

Async function calls

[Vladimir Prus]

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

Re: Async function calls

[Daniel Jacobowitz]

On Thu, Mar 20, 2008 at 10:44:46AM +0300, Vladimir Prus wrote:
> Maybe, somebody have bright ideas?

Could we pick out the inferior function calls and evaluate them first,
with continuations?  Except that could change order of evaluation;
we'd have to read the values of variables at the same time.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Async function calls

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Thu, Mar 20, 2008 at 10:44:46AM +0300, Vladimir Prus wrote:
>> Maybe, somebody have bright ideas?
> 
> Could we pick out the inferior function calls and evaluate them first,
> with continuations?  Except that could change order of evaluation;
> we'd have to read the values of variables at the same time.

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.

- Volodya

Re: Async function calls

[Daniel Jacobowitz]

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

Re: Async function calls

[Daniel Jacobowitz]

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

Re: Async function calls

[Michael Snyder]

On Thu, 2008-03-20 at 08:10 -0400, Daniel Jacobowitz wrote:
> On Thu, Mar 20, 2008 at 10:44:46AM +0300, Vladimir Prus wrote:
> > Maybe, somebody have bright ideas?
> 
> Could we pick out the inferior function calls and evaluate them first,
> with continuations?  Except that could change order of evaluation;
> we'd have to read the values of variables at the same time.

Sounds like a job for -- ax-gdb!