Re: [Evolution-hackers] Win32 portability issues

[Tor Lillqvist <tml novell com>]

Not Zed writes:
 > Yeah there's a good reason it is done.  You could check the hackers
 > archives perhaps for more discussion.  In short, because db's format
 > changes with different versions, we had to force a specific version.
 > And when we did that, distro's often had to build a separate libdb just
 > for evolution, which made it difficult for them. 

OK, I see. As the minor hacking required to make the included libdb
build with gcc on Win32 is already done anyway, I'll use it on Win32,
too. (Hmm, I don't know whether I will be able to run libdb's test
suite, though. That requires building the Tcl interface, doesn't it?
And the Tcl one would prefer to use is ActiveState's, and that then
again is set up for MSVC...)

 > I suppose there isn't much we can do about this.  I don't think GThread
 > even existed when we started, so that is definitely part of the reason.
 > Glib's api's are generally sucky, and with mutex's there is no
 > difference, e.g. forcing a completely different api for static mutexes
 > is quite annoying.

But on the other hand the source files in e-d-s that use static
mutexes already typically define shorthand macros to lock/unlock them,
so it wouldn't mean much change to instead use G_LOCK(foo) and
G_UNLOCK(foo). Surely it's as simple to have:

G_LOCK_DEFINE_STATIC(block_file);

and then use G_LOCK(block_file) and G_UNLOCK(block_file)

as:

static pthread_mutex_t block_file_lock = PTHREAD_MUTEX_INITIALIZER;
#define LOCK(x) pthread_mutex_lock(&x)
#define UNLOCK(x) pthread_mutex_unlock(&x)

and use LOCK(block_file_lock) and UNLOCK(block_file_lock) ?

 > It is also missing pthread_once.

(As you noticed later, there is g_once().)

One thing that *is* missing, though, is cancelling of threads. How
important do you see that the cancellability is? Or is it equivalent
if the thread's code "manually" checks for some cancel flag at
suitable places (the places where it currently calls
pthread_testcancel())?

Another maybe problematic thing is the <semaphore.h> stuff that
camel-object.c uses. I guess GCond corresponds to a semaphore as used
here, but its API is a bit different, and you need to have a GMutex
also associated with the GCond. I haven't looked at the code close
enough yet to see how easty it would be to switch. Would the existing
type_lock suffice to use as the GMutex associated with the GCond?

 > Camel has different requirements than most of eds, and comes from a
 > completely separate development stream. 

OK, I understand that the separate development history of different
parts explain much.

 > What is NIH?

Not-Invented-Here.

 > For example, the asynchronous dns lookup is cancellable using a
 > global camel cancellation mechanism, and it is thread-safe.

But libsoup also has (or at least, so it seems to me, from just
reading the code) asynchronous cancellable DNS lookup?

 > Camel cannot depend on many gnome-related libraries because of the
 > threading issue - including anything that uses gobject.

Hmm, please explain more... Are gobjects inherently non-thread-safe?

--tml