[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [Vala] Proposal for asynchronous DBus calls.
- From: "Christian Hergert" <christian hergert gmail com>
- To: "Sam Liddicott" <sam liddicott com>
- Cc: vala-list <vala-list gnome org>
- Subject: Re: [Vala] Proposal for asynchronous DBus calls.
- Date: Fri, 17 Oct 2008 03:08:39 -0700
Totally. Like I said, not really applicable, but figured I'd mention it.
With closures, the framework will stay the same, you just get access
to more locals as your user_data wont get hi-jacked by the instance,
but the closure data.
-- Christian
On Fri, Oct 17, 2008 at 2: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 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
>>>
>>>
>
>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]