Async function calls

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

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

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

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

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!