> sounds a lot less maintainable and in the long run less re-usable. i also
I agree, after some investigation, shared memory is a bit tedious to work with. > wonder if using shared memory wouldn't simply move, rather than remove, lock > contention for data population, etc. There /would/ be less locks, but it would be a big sanity trade-off :) > looking at the code in kactivities, the main problem seems to be that there > are (still) sync calls in the library. that's "ok" as long as it can be > guaranteed that the calls return quickly, which means that a) the daemon is > either running always (never crashes) or very quick to start, b) the daemon > can guarantee fast retrieval of the data, c) the daemon itself is never in a > sync call for very long. The most important parts are now mostly non-blocking (pre-fetched on the class instantiation, and cached) and the service is broke out into several separate threads to ensure the main part is not blocked by the rest. > attempts to provide synchronous access. perhaps it would be better to just > drop the pretense of synchronicity in the API? I don't like the idea of having a simple requests like activity list or info with async api. This would be quite imitating for simple clients like loopless kio_activities, or file item plugin. It would be nicer to have something like std::async(...some method...). For the slower methods (linked resources, and similar), I'd go for it, or remove it since we IIRC don't use it in any important place. Cheerio,, Ivan -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
