Re: [Vala] Documenting 'async' / WAS: Further speculations on couroutines, generators and threads : Emulating Go's goroutines and channels in Vala

[Jim Peters <jim uazu net>]

Serge Hulne wrote:
> 2. Async methods have virtually no use outside the scope of event-driven GTK+
> applications (except perhaps as a way to implement additional Vala features
> like Luca Bruno's generator, but at the cost of runtime-performance).

I think people will find uses for async methods if they understand how
they work.  Certainly when I was working coding GUI applications in
Java, there were many times I could have used this kind of method
(e.g. doing a long sequence of database queries and then presenting
the results on the GUI).  Instead I had to code up long chains of ugly
callbacks, or improvise other non-intuitive solutions.


> 3. There is always a way to write an equivalent program without
> async methods (with just ordinary function calls), except for
> applications with a graphical interface (GTK+ applications).
>
> 4. That a program avoiding async methods will always :
>         - be more readable (simpler).
>         - perform faster.

Not true.  It might be a lot more ugly without async depending on what
is being coded.

The speed cost of async is relative, i.e. if there is a lot more
processing or waiting happening than callbacks then the callback cost
won't be significant.

In your word-parsing example, though, the callback cost is
significant.  Also, I think that local temporary variables probably
can't be optimised away by the C compiler in async methods, because
they are stored in a structure.  So there may be a performance hit
because of that.


> 5. That async methods are not about runtime performance, but exclusively about:
>         - callbacks for graphical interfaces.
>         - convenience (as an alternative to an ordinary function call, when it
> seems convenient to do so).
>
> 6. That async methods are not at all meant to provide a way to run ancillary
> tasks in the background, in order to gain runtime performance.

You can implement an async method which creates a background thread
and yields until the thread completes.


> Question about combining async and threads in the "generator example":
>
> - Would it be possible to combine the last two examples for the following
> purpose:
>
> - Would it not be possible alternatively, for the generator, to call (slightly
> more indirectly) the feed() function in an independent thread,  accumulate the
> last N results in a queue (N being a parameter to pass to the generator), so
> that the generator would still appear to return one result at time, in order,
> but in fact they would be pulled from the queue, while the feed function keeps
> running in the background feeding the queue (the queue would act as a buffer,
> storing the last N results of the feed() method).

This doesn't need async methods at all.  You could write a normal
iterator which starts a thread and sets up an async queue and waits on
one end whilst the thread fills it on the other end.

You pay for thread startup time, plus any locking/synchronization
overhead.  You gain because of the buffering in the queue, plus the
ability to spread the load over different cores.  It is a trade-off
which could go either way according to the specific case.

If you want to spend all day optimising the Generator, you could also
try implementing 'fast iterators' like in Apple Objective-C, where the
generator code fills a buffer with N items, and then iterator runs
through emptying it, and then they switch again.

Jim

-- 
 Jim Peters                  (_)/=\~/_(_)                 jim uazu net
                          (_)  /=\  ~/_  (_)
 Uazú                  (_)    /=\    ~/_    (_)                http://
 in Peru            (_) ____ /=\ ____ ~/_ ____ (_)            uazu.net