KActivities library optimizations

[Ivan Čukić]

> 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