Re: [Evolution-hackers] Win32 portability issues

On Wed, 2005-05-04 at 12:51 +0300, Tor Lillqvist wrote:
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:


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

Well, yes and no.  G_LOCK() calls g_static_mutex_lock, and isn't the same as calling g_mutex_lock().  So there ARE distinct functions for each type and you have to remember which it is, even if you only have to remember in one place.  That makes the api more complex than pthread's, correct?

It's really not a major problem ... just a comment.

 > 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

We don't use pthread_cancel except for the async dns lookup.  Camel's cancellation is a combination of polling (as in test function) and i/o polling (for multiple-wait) which sets an exception which falls out of the function/thread.  It's just too hard to implement stuff so pthread_cancel works properly, and it had a lot of bugs back then anyway.

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?

There is a specific reason i used a semaphore, although I can't recall why.  Maybe a cond didn't work for some weird edge case, or maybe it just seemed a better fit at the time.

 > 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?

Doesn't it rely on the gmainloop?  We can't use that.

 > 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?

Yes, they are inherently non thread-safe.  The code is also so wildly complex that it is difficult to know, even if it claimed to be.

So how bad is the posix api for other stuff, like file i/o, sockets, etc?

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