| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Because it's really the application domain and not the akonadi domain.
|
| | |
|
| | |
|
| |
|
|
|
| |
All identifiers should be latin1 and we make this explicit by using
QByteArray. QString is reserved for strings that can be UTF-8 or alike.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Ideally we wouldn't be copying at all, and somehow cast the table to a vector.
Unfortunately I haven't figured out how to do that, and this solution at least
gets us from 0.065 ms to 0.028 ms in testCreateCommand.
|
| |
|
|
| |
To measure overhead of the communication to the separate process.
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Storing Future and current Job progress directly in Executors means
that we cannot re-execute finished job, or even execute the same Job
multiple times in parallel. To do so, we need to make Executors stateless
and track the state elsewhere.
This change does that by moving the execution state from Executor to Execution
class. Executors now only describe the tasks to execute, while Execution holds
the current state of execution. New Execution is created every time Job::exec()
is called.
Execution holds reference to it's result (Future) and Executor which created
the Execution. This ensures that Executor is not deleted when Job (which owns
Executors) goes out of scope while the execution is still running. At the same
time Future holds reference to relevant Execution, so that the Execution is
deleted when all copies of Future referring result from the respective Execution
are deleted.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's lifetime is limited to the end of the function, so we have to copy it before.
I switched to QByteArray because it simplifies the code and shouldn't really
cost anything, additionally the implicit sharing makes copies cheap.
This patch incurs the cost of always copying the buffer instead of writing
straight to the socket, but we probably anyways want to keep a copy around,
and if it would indeed be a performance issues (I doubt it), we could still optimize
that copy away.
|
| | | |
|
| | |
| |
| |
| | |
We indeed have to keep the facade alive, otherwise this starts crashing.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
The only reference to the top executor (the last in chain) is held by the
Job. If the Job goes out of scope after it's executed, the top Executor
is deleted (which in turn deletes the entire Executor chain). By having
the top Executor holding reference to itself during execution we ensure
that the Executor chain is not deleted until the job is finished, even
when the parent Job object is deleted in the meanwhile.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
lifetime tests.
|
| | |
|
| |
|
|
|
| |
There's a chance that the resource actually wanted to shut-down. Instead
ResourceAccess should only reopen the connection if it still has work to do.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Otherwise the client always restarts the resource because of the lost connection.
We currently require this in tests to be able to delete the db, but eventually
we likely want a "disable akonadi" function that shuts resources down,
and keeps clients from restarting them (e.g. via configuration).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is now possible use KJob-derived jobs with libasync without having to write
lambda wrappers.
auto job = Async::start<ReturnType, MyKJob, MyKJob::result, Args ...)
.then<ReturnType, OtherKJob, OtherKJob::result, PrevKJobReturnType>();
job.exec(arg1, arg2, ...);
The reason for this approach (instead of taking KJob* as an argument is that
we usually want the KJob ctor arguments to depend on result of previous job.
At least in case of Async::start() however it makes sense to support passing
KJob* as an argument (not yet implemented).
In future we should also support custom error handlers.
The KJob integration is build-time optional, but enabled by default (pass
-DWITH_KJOB=FALSE to CMake to disable).
Adds KCoreAddons dependency.
|
| |
|
|
|
|
|
|
| |
It is now possible to chain a job that takes no arguments after a job
that returns void.
Unfortunatelly it is not yet possible to disregard return value of a
previous job.
|
| |
|
|
|
|
|
|
|
| |
When user gets a Job (from a method call for instance), which is already running
or might have even finished already, they can still append a new Job to the chain
and re-execute it. The Job will internally chain up to the last finished Job, use
it's result and continue from the next Job in the chain. If a Job in the chain is
still running, it will wait for it to finish and pass the result to the next Job
in the chain.
|
| | |
|
| |
|
|
| |
multiple times
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now it's possible to do something like
Job<int, int> job = createSomeJob();
auto main = Async::start<int>(....).then(job);
Previously the 'job' would have to be wrapped in a ThenTask-like lambda (which
is what we still do internally), but with this new syntax it's possible to append
another job chain to existing chain easilly. This syntax is available for all
task types.
|
| |
|
|
|
| |
The initial value can be passed in as argument to Job::exec(), or by another
job in case of job chaining.
|
| | |
|
| | |
|
