Re: Valgrind meets UML

[Jeff Dike]

This is gibberish.  You have no idea what you're talking about.

[e-mail] said:
> But in the abstract, and more importantly in the mind of the
> maintainer of a lock-free SMP allocator 

"lock-free SMP"?  This is very nearly a self-contradiction.  If you'd bother
looking at the allocators, guess what you'll see?  You'll see locking.

> who is trying to allow
> simultaneous allocation and valgrind of the allocator, 

There is no "allowing" simultaneous allocation and valgrind of the allocator.

> then such atomicity problems are real.

Bullshit, there are no such atomicity problems.

> If nothing else, then such a maintainer will invent his own VALGRIND_*
> usage to express simultaneous {allocator, valgrind} state transitions
> precisely.

A maintainer will invent valgrind primitives to express concepts that valgrind
doesn't know about?  

> to express simultaneous {allocator, valgrind} state transitions
> precisely.

There are no simultaneous allocator and valgrind state transitions.

You really need to acquire a clue from somewhere.

				Jeff