On 12/06/2011 04:56 PM, ext Jonas Gastal wrote: > (...) >>> That's a slightly different problem. With WebKit 2, we have different >> processes, >>> so different instances of QAbstractNetworkCache. The problem then is not >> to >>> make the class be thread-safe, but to make the cache methodology be >> multi- >>> process-safe.
Yes, it was my exact point to note that this is a different problem; and of course QMutex does not help here. > Sorry if this is a stupid point, but there is a pretty standard mechanism > for > multiprocess "mutexes" in the form of ".lock" files. Isn't this an obvious > and > acceptable solution(to that part of the issue)? They have the same up/down > sides of actual mutexes. It might be; other options include QSharedMemory or whatever boost::interprocess::file_lock does. My point was more that there might be more logic needed on top of the disk cache, because we had plans to keep some items in memory (as browsers do), which we then maybe would need to synchronize; in addition we would need something for a persistent cookie jar where you do not want to read from / write to disk for each single cookie. So my point was: Let's keep the WebKit2 use case in mind when redesigning the cache / persisting the cookie jar etc. Peter > > Gastal. > > > > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
