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