On Wed, Jul 13, 2011 at 15:17, august <[email protected]> wrote: > "With asynchronous methods it is possible to do programming without > any blocking." > > The following examples in the tutorial are much more enlightening...so > it's not that bad. But, maybe it could be improved. >
Async methods were created primarily for GIO to do non-blocking IO. Doing IO usually blocks the application and so freezes the UI, so the GLib answer is to provide callbacks to be called when the IO is done and the program can keep executing while IO is done in the background (note here that background does not necessarily mean another thread, the IO can be done by the kernel and notify the process when it's complete). > I always thought async methods: > a) are always single threaded > b) uses the glib runtime scheduler to simulate > multi-processes > c) cannot take advantage of multi-core or multi-processor > computers > Async methods have nothing to do with threads, so none of these points are valid. However, what async methods allow is to stop the processing of a function in the middle and resume it after the async method returns, by the means of the callbacks. So, what the async method can do is spawn a thread to do background processing and later call the callback to resume the operation of the method that called it. Which means async methods can be just as blocking as any other method if it does sequential processing and at the end calls the callback. But also means it can be designed to use any other way to provide background processing (including threads) without blocking the main program (especially the UI) and thus can take advantage of multiple cores. At least this is what I understood so far about async methods, please let me know if any of this is wrong. Regards, Alexandre
_______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
