paul wrote:
> On 5/3/2012 12:50 AM, Paul Fox wrote:
> > this is just curiousity on my part: why does it matter? i've always
> > figured that compared to the expense of actually doing things to the
> > files one is locking, the taking and releasing of the lock itself is
> > in the noise, perf
>this is just curiousity on my part: why does it matter? i've always
>figured that compared to the expense of actually doing things to the
>files one is locking, the taking and releasing of the lock itself is
>in the noise, performance-wise. is one set of locking primitives
>that much better tha
On 5/3/2012 12:50 AM, Paul Fox wrote:
> this is just curiousity on my part: why does it matter? i've always
> figured that compared to the expense of actually doing things to the
> files one is locking, the taking and releasing of the lock itself is
> in the noise, performance-wise. is one set o
ken wrote:
>
> I'm assuming we don't want a biglock because that would cause more lock
> contention, but maybe that wouldn't ever be a real problem in practice.
>
> So I think now you're starting to see the mess that nmh locking is. I was
> close to cleaning it up, but I just got tired and
>>it is now (unless you wanted to do the equivalent of a biglock; we don't
>>want that, do we?).
>
>I don't know why we don't want that. But there is no reason why I need to know.
>At this point I retire from this locking discussion with the hope that I don't
>gag on all the feet in my mouth.
I'm
Ken Hornstein writes:
>>>But then you say (in another message) that you want nmh programs to not
>>>deadlock under our hypothetical nmhlock program
>>
>>If I said something that amounted to that, it's not what I meant. I don't know
>>what I might have said that led you to believe that's what I mea
