My interest is more on using async calls than implementing libraries
that support async calls. It is more close to Jurg's idea.
Studying the framework of GIO async and DBus async, I found complexity
there.
Those two asyncs are already different and if we want to support more
async libraries, the complexity will grow.
GIO:
void g_io_scheduler_push_job
(GIOSchedulerJobFunc job_func,
gpointer user_data,
GDestroyNotify notify,
gint io_priority,
GCancell
DBusGProxyCall* dbus_g_proxy_begin_call (DBusGProxy *proxy,
const char *method,
DBusGProxyCallNotify
notify,
gpointer data,
GDestroyNotify destroy,
GType first_arg_type,
...);
the location of 'self' are different. The return values differ (the way
to handle cancel), and there is no 'finsished' callback for GIO at all.
Some very clever CCode attributes has to be added to the vapi files.
The difference is deeper than it looks. GIO job is defined by the user
code. Whereas DBus job is done by external code.
anyways, GIO is not yet endemic to VALA, but DBus already is. If async
is ever going to happen, I would suggest putting DBus to the first
priority.
Yu
On Sat, 2008-10-18 at 07:52 +0200, Jürg Billeter wrote:
> On Sat, 2008-10-18 at 00:42 -0400, Yu Feng wrote:
> > On Fri, 2008-10-17 at 07:44 +0100, Sam Liddicott wrote:
> > > If you seach recent vala posts by me, you'll see some discusion on this
> > > topic.
> > >
> > I really got lost in the sea of emails. What is the title of the
> > disscussion?
> Have a look at the thread 'Implicit lamdas/closures'
> http://mail.gnome.org/archives/vala-list/2008-September/msg00053.html
>
> Jürg
>
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
