Re: [Evolution-hackers] Win32 portability issues

[Jeffrey Stedfast <fejj novell com>]

On Wed, 2005-05-04 at 18:31 +0530, Not Zed wrote:
> 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.

the semaphores were definitely aded later and replaced some other
locking mechanism. all I remember is there was some race condition at
startup or something I think.

Jeff