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 _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
