On Fri, Oct 17, 2008 at 11:25 AM, Sam Liddicott <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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
>
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
