View Single Post
Old 10-29-2010, 12:59 PM   #18
Valloric
Created Sigil, FlightCrew
Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.
 
Valloric's Avatar
 
Posts: 1,982
Karma: 350515
Join Date: Feb 2008
Device: Kobo Clara HD
Quote:
Originally Posted by KevinH View Post
I wonder ... if thread 3 was doing the following:

const QString &atrribute_value = Utility::URLDecodePath( XtoQ( attribute.getValue() ) );

at the same time that thread 4 was doing

attribute.setValue( QtoX( Utility::URLEncodePath( new_path ) ) );
We're talking about the PerformHTMLUpdates::UpdateReferenceInNode function, right? Take a look at PerformHTMLUpdates::UpdateHTMLReferences function just above it. All the "path" nodes are retrieved at once, and then every one is independently scheduled for possible updates by QtConcurrent.

Since XhtmlDoc::GetTagMatchingDescendants should only return unique nodes, no two entrances on UpdateReferenceInNode should use the same node. Meaning that while that function is not thread safe, it is reentrant and that's all we need here.
Valloric is offline   Reply With Quote