Re: [Vala] Thoughts on asynchronous methods

[Jiří Zárevúcky <zarevucky jiri gmail com>]

On 09/12/2009 01:34 PM, Jürg Billeter wrote:
> Hi Jiří,
>
> [...]
> As async support is still considered experimental, I think it makes
> sense to change the keyword now. I don't know whether we should use
> `async' or rather the unabbreviated `asynchronous' to be clear, although
> it's quite long. Any opinions?
>
>    

'asynchronous' is too long IMO. 'async' is quite obvious, it's used in 
other libraries then GIO as well.

> > --------------------------------------------------------
> > 2. purely asynchronous methods
> > --------------------------------------------------------
> >
> > There are actions that can't be represented synchronously and methods
> > where synchronous variant needs to be written separately. 'nuff said.
> > This could perhaps be handled using specialized [Async] attribute with
> > appropriate parameters.
> >      
> For this exact reason - and the fact that sometimes parameter lists
> differ slightly between sync and async variants -, I'm actually tending
> to drop the combined sync/async method support, and only support purely
> asynchronous methods. While combined methods sound interesting, they are
> not essential, and I prefer a solid slightly simpler async support to
> advanced async support with issues.
>
>    

I don't know about removing altogether. AFAIK it just feeds the normal 
codegen with the same data, no big deal. Maybe it would be more 
reasonable to disable by default with some attribute for enabling?

> > -----------------------------------------------------------------------
> > 3. stopping execution until a callback yields
> > -----------------------------------------------------------------------
> >
> > There are actions that can be described as "waiting for callback". For
> > that to work correctly, programmer needs to make sure all the connected
> > callbacks are disconnected as the method returns. If there is mechanism
> > to "pause execution" (from the programmers POV) until some connected
> > callback yields, it would allow doing this cleanup in a finally block.
> > I have a faint feeling that bare "yield" keyword already has some
> > semantics, but for the sake of demonstration:
> >
> >       public int method () yields throws Error{
> >           try {
> >               signal1.connect ((x) =>  yield return x;);
> >               signal2.connect ((x) =>  yield throw new Error ("Error
> > occured: %s", x););  // the first one to be executed decides the return
> > condition
> >
> >               yield;   // wait and treat yields as if they were called here
> >           }
> >           finally {
> >               signal1.disconnect ();
> >               signal2.disconnect ();
> >           }
> >       }
> >
> > This is also a prime example of method that can't be translated into a
> > synchronous version.
> >
> > -------------------------------------------
> > 4. co-execution operator
> > -------------------------------------------
> >
> > [...]
> >      
> This is an interesting idea. However, I hope you understand that it
> doesn't make sense to me to closely look into things like that until
> basic async support is working well - and Vala 1.0 has been released.
>
>    

Sure, the basic support is hardly usable at the moment, so these 
features (if accepted) may not be realized for some time. This is just 
for the sake of sharing ideas and discussion.

> Jürg
>
>