Re: [Evolution-hackers] Camel Manifesto (update)

[David Woodhouse <dwmw2 infradead org>]

On Mon, 2010-09-27 at 12:52 -0400, Matthew Barnes wrote:
> 3. Asynchronous Methods
> -----------------------
> 
> All the upgrades I've been making to Camel over the past year, and all
> the changes described above were in preparation for this: Camel now has
> an asynchronous public API.
> 
> Let me immediately point out that there is ZERO IMPACT TO EXISTING CAMEL
> PROVIDERS beyond the API changes I mentioned above.  Camel providers
> need not do anything special to support the new asynchronous methods.
> As in GIO, all async methods default to simply calling the corresponding
> synchronous method from a thread pool, which is all Evolution does.

I was told today that the GIO (and libsoup) async methods may not be
called from a thread other than the one running the mainloop. I found a
stupid race in libsoup¹ and filed a fix, but the bug was closed INVALID
because apparently it's not *supposed* to be thread-safe.

That's a serious issue for using it from Evolution; it means we have to
jump through stupid hoops like using idle callbacks to call it from the
main thread, just as we do for gconf.

Apparently, gio suffers this brain-damage too.

I assume that your intention is that the Camel async methods would *not*
be similarly broken, and that you should be able to call them from *any*
thread and expect them not to break?

If so, we need be *very* careful about calling into gio.

I think perhaps we need to reset expectations about what a sane API
looks like in the 21st century. We are all set to stop using gconf,
print out its source code, and ritually urinate on it and then burn it.
In part because it's not thread-safe and we have to do stupid things to
ensure we call into it from the main thread. And yet people are still
implementing new APIs with the *same* problem...

-- 
dwmw2

¹ https://bugzilla.gnome.org/show_bug.cgi?id=642573