Re: commit: recursive locking

From: Patrick Lam (plam@plam.lcs.mit.edu)
Date: Mon Aug 05 2002 - 08:57:09 EDT

  • Next message: Martin Sevior: "Re: commit: recursive locking"

    On Mon, Aug 05, 2002 at 12:43:42AM -0700, Joaquin Cuenca Abela wrote:
    > 1) I will like to know if it affects performance.

    I can't measure that on my computer.

    > 2) Any reason for the mutex to be allocated on the
    > heap and not in the stack? That way you will not lack
    > it at the end of abiword.

    The mutex is static, so there's one which exists throughout the
    lifetime of the program. Or that's what I meant to do; I mistyped
    my patch, it should really say if (!m_grLock) m_grLock = new UT_Mutex();

    > 3) Not all the operations on GR_UnixGraphics do X
    > calls. Character measurement (half of them in the
    > normal X build, and all them in the Xft build) don't
    > makes any X call. Remember that we do *a lot* of
    > character measurements...

    I'm not sure which glib calls correspond to X calls or not.
    e.g. I suspect that gdk_gc_set_line_attributes doesn't, but I don't
    know for sure. I will remove the lock around measureUnRemappedChar.
    (What about _setColor?)

    > 4) Please, commit first my previous patches for
    > GR_UnixGraphics, the least our patches conflicts, the
    > best.

    My patch is actually quite simple and conflicts should be easy to merge.

    > If you're going the GR_Caret way, at least give a
    > GR_CaretHidder class or something like that.

    I thought I had one already. Anyway I'll implement one soon if
    there isn't one already.

    Bah, I have to run now and cvs is being too slow.

    pat



    This archive was generated by hypermail 2.1.4 : Thu Aug 08 2002 - 08:55:07 EDT