1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
.. _sync_code:
Run synchronous code
====================
Synchronous code will block the event loop and degrade the performance
of the Quart application it is run in. This is because the synchronous
code will block the task it is run in and in addition block the event
loop. It is for this reason that synchronous code is best avoided,
with asynchronous versions used in preference.
It is likely though that you will need to use a third party library
that is synchronous as there is no asynchronous version to use in its
place. In this situation it is common to run the synchronous code in a
thread pool executor so that it doesn't block the event loop and hence
degrade the performance of the Quart application. This can be a bit
tricky to do, so Quart provides some helpers to do so. Firstly any
synchronous route will be run in an executor, i.e.
.. code-block:: python
@app.route("/")
def sync():
method = request.method
...
will result in the sync function being run in a thread. Note that you
are still within the :ref:`contexts`, and hence you can still access
the ``request``, ``current_app`` and other globals.
The following functionality accepts synchronous functions and will run
them in a thread,
- Route handlers
- Endpoint handlers
- Error handlers
- Context processors
- Before request
- Before websocket
- Before first request
- Before serving
- After request
- After websocket
- After serving
- Teardown request
- Teardown websocket
- Teardown app context
- Open session
- Make null session
- Save session
Context usage
-------------
Whilst you can access the ``request`` and other globals in synchronous
routes you will be unable to await coroutine functions. To work around
this Quart provides :meth:`~quart.app.Quart.run_sync` which can be
used as so,
.. code-block:: python
@app.route("/")
async def sync_within():
data = await request.get_json()
def sync_processor():
# does something with data
...
result = await run_sync(sync_processor)()
return result
this is similar to utilising the asyncio run_in_executor function,
.. code-block:: python
@app.route("/")
async def sync_within():
data = await request.get_json()
def sync_processor():
# does something with data
...
result = await asyncio.get_running_loop().run_in_executor(
None, sync_processor
)
return result
.. note::
The run_in_executor function does not copy the current context,
whereas the run_sync method does. It is for this reason that the
latter is recommended. Without the copied context the ``request``
and other globals will not be accessible.
|
