Re: [Vala] Proposal for asynchronous DBus calls.

["Ali Sabil" <ali sabil gmail com>]

On Fri, Oct 17, 2008 at 11:25 AM, Sam Liddicott <sam liddicott com> wrote:

* Christian Hergert wrote, On 17/10/08 09:24:

> For tasks, you have two options.
>
> 1) Create a GTask with a callback and user_data.
> 2) Inherit from GTask and implement the execute (and optionally,
> cancel) methods.
>
> Keen observers will notice my challenge right away. Yes, I inherit
> from GObject for reference counting and general ease of use.  It was a
> tough choice.  That may make scalability an interesting feat without
> reusing tasks with a sort of free-list (a la threading building
> blocks).
>
> Point being, your shared variables will live in the "target" of your GTaskFunc.
>
> And the prototype for sake of link jumping.
>
> typedef GTask* (*GTaskFunc) (GTask *task, GError **error, gpointer user_data);
>
> Notice how a task/callback/errback can pause further execution of the
> state machine by returning another task immediately.  Errback's will
> have the option to free and unset error to allow for further
> processing of the callback chain.  Not quite sure how to handle this
> in vala bindings yet. I'm considering dropping error from the
> prototype and adding it as tasks methods (task.{get/set}_error).
>

heh.

I want to do async handlers in order to avoid writing the state machine,
and to avoid having to declare a class with all my shared variables.

I want to write a linear function and "not mind" if it gets broken up.

I think I agree with you on this, and we have been avoiding this in People[1] by building a small set of classes, that allow pretty easy asynchronous programming, without the headache of declaring a new class, you can find them in [2] and [3].

I think that once vala supports closures, it would be possible to create easy to use and powerful asynchronous frameworks.

Cheers,

[1] https://launchpad.net/people-project
[2] http://bazaar.launchpad.net/~people-project/people-project/people-trunk/annotate/336?file_id=asyncoperation.vala-20080229110024-3hje2bxh4o28ycx5-1
[3] http://bazaar.launchpad.net/~people-project/people-project/people-trunk/annotate/336?file_id=asyncsearch.vala-20080321133806-j20pjqwqipnrivhf-1
--
Ali
 

I suspect this is because I am user of someone elses async framework,
you are trying to devise an async framework.

 

Sam

> -- Christian
>
> On Fri, Oct 17, 2008 at 1:05 AM, Sam Liddicott <sam liddicott com> wrote:
>
>> * Christian Hergert wrote, On 17/10/08 08:06:
>>
>>> This isn't totally applicable, but I thought I'd mention it before too
>>> much more async voodo.
>>>
>>> I've been working on an asynchronous toolkit library for GObject so
>>> that once we get "yield return/yield break" support I can implement my
>>> ideas I posted earlier.
>>>
>>> The library is called GTask and can be found on github[1].  For a
>>> quick, totally out of context example:
>>>
>>> var task = new Task (_ => {
>>>     debug ("im in worker thread");
>>> });
>>>
>>> task.add_callback (_ => {
>>>     debug ("im in main thread, by default");
>>> });
>>>
>>> task.add_errback (_ => {
>>>     debug ("i can resolve an asynchronous error");
>>> });
>>>
>>> You can build complex callback/errback chains just like in Python
>>> Twisted.  By default, the task scheduler will dispatch callbacks and
>>> errbacks from the main thread to ease locking hell for GUI
>>>
>>>
>> This looks a similar pattern to that used in samba's composite connect;
>> I think it is useful.
>>
>> How will shared variables be expressed?
>>
>> Sam
>>
>>

_______________________________________________
Vala-list mailing list
Vala-list gnome org
http://mail.gnome.org/mailman/listinfo/vala-list