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 (_)/=\~/_(_) [email protected] (_) /=\ ~/_ (_) Uazú (_) /=\ ~/_ (_) http:// in Peru (_) ____ /=\ ____ ~/_ ____ (_) uazu.net _______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
