[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Vala] Proposal for asynchronous DBus calls.



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]