Since PipelineC is not thread-safe, add a lock to all function calls to
it to avoid any thread safety-related issues.
At the same time, use a thread pool to run "expensive" PipelineC
functions in GraphQL (specifically `produce_target` and `run_analysis`)
to avoid problems due to the cooperative nature of Python coroutines.
This commit adds the newly implemented functionality in PipelineC both
in revng.api and the graphql api, allowing:
* retrieval of global variable names
* unwrapping of a single target
* execution of analyses
--production runs the server on all interfaces and with debug options
disabled
--hypercorn-args allows to pass extra options to hypercorn when running
revng daemon
In the future we will need to use GraphQL subscriptions. This is done
via websockets and is supported in Ariadne. However this support is
limited to ASGI frameworks, which Flask isn't a part of.
Startlette is a direct depencency of Ariadne, and all of Ariadne's
features are fully integrated with Starlette, so the switch allows to
drop some Flask integration cruft and streamline the revng.daemon
package.
Starlette does not have a built-in development server, instead
Hypercorn, which is an ASGI-compliant HTTP server, is used in place of
Flask's Werkzeug/Gunicorn for both the development and production
server roles.
Fix termination of the daemon process during test, previously it was the
daemon instances were not cleaned up properly and remained running after
the tests
This commit introduces the `revng.daemon` Python module, a Flask-powered
web application that exposes the functionality from `revng.api` across a
GraphQL API
We used to collect all binaries into the `bin/` directory. However this
led to confusions since certain commands where available both as
`revng-command` and `revng command`.
This commit moves all the executables except `revng` into
`libexec/revng`, which, according to FHS, is dedicated to "internal
binaries that are not intended to be executed directly by users or shell
scripts".
Giacomo Vercesi