Ted: I noticed on the bugs/commit list you were asking about a lock in the
iterator::peek() method.
> // ??? This lock seems odd. We are returning a pointer to the
> // MappedEvent in the buffer. So the caller uses a pointer
> // into the buffer after the read lock is released. Is that
> // correct? That would mean that this lock only locks the
> // container, not the elements in the container. This would
> // prevent changes to the "fill" before getting the element.
I can shed a little light on it, though not as much as I'd like. I was
very conservative about what I changed, as you have noticed with the
isMetronome method, "res"/"resize", et al. The lock comes from before my
time, so I may not fully understand its purpose, but I'll tell you what I
can.
One thing with the mappers is that we accept a few glitches if the segment
(etc) is being edited while we're playing. It's been that way for a long
time and it seems to be tolerable to users.
What the lock prevents is grabbing an event just as resizeBuffer
reallocates the whole buffer. Then the pointer points into deleted space.
And yes, ISTM it should lock in the caller, not in peek. fillNoncompeting
is the only caller. It passes the pointer to inserters, but those just
(normal) copy the event or (midi) make something else, so that's the full
extent of the pointer exposure.
I notice you've done a lot of fine work on this, Ted. Thank you.
I noticed you commented about the isMetronome method. I fully agree. As
I mentioned, I was very conservative in what I changed. Really, the whole
"else if (cur->getType() == X)" / acceptEvent maze seems to be the proper
concern of the various derived classes.
I'm reluctant to edit the code while you are working on the same files,
and I trust your judgement.
Tom Breton (Tehom)
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
