lkml.org 
[lkml]   [2006]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Compiling C++ modules
    Valdis.Kletnieks@vt.edu wrote:
    >
    > On Tue, 25 Apr 2006 20:53:01 +0300, Avi Kivity said:
    >
    > > Additionally, C++ guarantees that if an exception is thrown after
    > > spin_lock() is called, then the spin_unlock() will also be called.
    > > That's an interesting mechanism by itself.
    >
    > Gaak. So let me get this straight - We lock something, then we hit
    > an exception because something corrupted the lock. Then we *unlock* it
    > so more code can trip over it.
    >
    > Sometimes the correct semantic is to *leave it locked*.
    >
    C++ doesn't force *any* semantic on you. It gives you tools to implement
    the semantic you want. If you want the lock to remain unlocked, that is
    of course doable.

    Most often (almost always), the cause of the exception is not random
    corruption, but an error (I/O error, out of memory, etc.) and you want
    to unlock the lock. C++ helps you get it right without writing tons of
    boilerplate code:

    [avi@cleopatra linux]$ grep -r out.*: . | wc -l
    10446

    How many times you want it unlocked but it's left locked because of an
    obscure error path? When does 2.6.16.14 come out?

    --
    Do not meddle in the internals of kernels, for they are subtle and quick to panic.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-04-25 20:29    [W:4.036 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site