summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Unbreak the clientapi.Christian Mollekopf2015-04-02
| | | | We indeed have to keep the facade alive, otherwise this starts crashing.
* Cleanup and debug messages.Christian Mollekopf2015-04-02
|
* Async: have the top executor reference itself during executionDan Vrátil2015-04-01
| | | | | | | | | 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.
* Use dowhileChristian Mollekopf2015-04-01
|
* dowhile cleanup, second dowhile version without separate condition.Christian Mollekopf2015-04-01
|
* Refactored resourcefactory further.Christian Mollekopf2015-04-01
|
* Use Async::whileChristian Mollekopf2015-04-01
|
* Added Async::dowhileChristian Mollekopf2015-04-01
|
* async simplificationsChristian Mollekopf2015-03-31
|
* async todosChristian Mollekopf2015-03-31
|
* Attempt of a description how async is supposed to work, failing async ↵Christian Mollekopf2015-03-31
| | | | lifetime tests.
* Storage: API cleanup/use QByteArray instead of std::stringChristian Mollekopf2015-03-31
|
* Don't try to restart the resource on every disconnect.Christian Mollekopf2015-03-31
| | | | | 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.
* Forgot to compile the notification schemaChristian Mollekopf2015-03-31
|
* Don't leak the listener instance to catch problems with object lifetimes.Christian Mollekopf2015-03-31
|
* Minor cleanup, less warnings.Christian Mollekopf2015-03-31
|
* Shutdown notification to achieve a clean shutdown.Christian Mollekopf2015-03-31
| | | | | | | 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).
* Resource crashhandler and logging facilities.Christian Mollekopf2015-03-31
|
* Async: initial support for native chaining of KJobsDan Vrátil2015-03-30
| | | | | | | | | | | | | | | | | | | | | | 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.
* Async: allow consumer continuation without argumentsDan Vrátil2015-03-30
| | | | | | | | 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.
* Async: allow appending Jobs to already running or finished JobsDan Vrátil2015-02-21
| | | | | | | | | 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.
* CMake: fix Qt5 lookup, use KDE_INSTALL_TARGETS_DEFAULT_ARGSDan Vrátil2015-02-21
|
* Async: only notify watchers once when Future::setFinished() is called ↵Dan Vrátil2015-02-20
| | | | multiple times
* Async: allow appending existing Job objects to the Job chainDan Vrátil2015-02-20
| | | | | | | | | | | | 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.
* Async: allow Async::start() to have input valueDan Vrátil2015-02-20
| | | | | The initial value can be passed in as argument to Job::exec(), or by another job in case of job chaining.
* Async: beautificationDan Vrátil2015-02-09
|
* Async: move public API implementationDan Vrátil2015-02-09
|
* Async: Move Async::PrevOut to Async::detail::prevOutDan Vrátil2015-02-09
|
* Async: improve error handlingDan Vrátil2015-02-09
| | | | | | All jobs and executors now accept ErrorHandler argument which will be invoked on error. Error handling itself has been moved to Executor::exec(), so that we don't have to copy-paste the error handling code into every Executor implementation.
* Async: introduce sync executorsDan Vrátil2015-02-09
| | | | | | | | | Sync executors don't pass Async::Future into the user-provided tasks, but instead work with return values of the task methods, wrapping them into the Async::Future internally. Sync tasks are of course possible since forever, but not the API for those tasks is much cleaner, for users don't have to deal with "future" in synchronous tasks, for instance when synchronously processing results of an async task before passing the data to another async task.
* note on branching model for devAaron Seigo2015-02-09
|
* catch unqlite impl up to current Storage APIAaron Seigo2015-02-09
|
* void const -> const voidAaron Seigo2015-02-09
| | | | | equivalent syntax, but follows the standard idiom we use throughout the code .. const char *, not char const * (e.g.)
* Async: don't leak ExecutorsDan Vrátil2015-02-07
| | | | | | We now hold executors in shared pointers. We cannot easilly delete them, as they are referenced from two objects (the Job they belong to, and the next job), and the lifetime of the jobs is unclear.
* AsyncTest: block until innerJob finishes to prevent crashDan Vrátil2015-02-07
| | | | | | | innerJob.exec() starts an async job, so once exec() returns, the innerJob will go out of scope and will be deleted, which however does not prevent the QTimer from invoking it's lambda slot, which will crash when dereferencing a deleted Future.
* Async: mark our future as finished after returning from error handlerDan Vrátil2015-02-07
| | | | | | Error handlers don't have access to the future, so they can't mark it as finished, so we do it after the error handler is run. This ensures that FutureWatchers will finish.
* Async: remove unused FutureWatchersDan Vrátil2015-02-02
|
* Added JOBAPI todo's.Christian Mollekopf2015-02-02
| | | | Work for dvratil.
* clenupChristian Mollekopf2015-01-30
|
* Shutdown command for synchronizers, used by the dummyresourcetest.Christian Mollekopf2015-01-30
| | | | | Otherwise the synchronizer keeps a Storage object alive, while the tests deletes the db. This causes subsequent writes to fail in the next test.
* Open the database readonly in readonly mode.Christian Mollekopf2015-01-30
|
* DummyResourceBenchmarkChristian Mollekopf2015-01-27
|
* introduce a set of isInternalKey functions to hide this impl detailAaron Seigo2015-01-27
|
* can not delete this as it is an opaque data structureAaron Seigo2015-01-27
| | | | instead, use the lmdb api
* fix buildAaron Seigo2015-01-27
|
* Don't enlessly block in the eventloop.Christian Mollekopf2015-01-27
| | | | | The job currently finishes synchronously. If we just use the eventloop in waitForFinished that's automatically handled for us.
* Avoid shutting down the synchronizer all the time.Christian Mollekopf2015-01-25
|
* debug outputChristian Mollekopf2015-01-25
|
* Stop using Akonadi2::Console.Christian Mollekopf2015-01-25
| | | | We need a decent loggin framework.
* Propagate errors for commands.Christian Mollekopf2015-01-25
|