Re: [Evolution-hackers] Win32 portability issues

[Not Zed <notzed ximian com>]

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:
>
> G_LOCK_DEFINE_STATIC(block_file);
>
> 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
> pthread_testcancel())?

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?