Native asyncio support

[thorin-schiffer]

Checklist

• [X] I have searched the existing issues for similar feature requests.
• [X] I added a descriptive title and summary to this issue.

Summary

Streamlit needs native asyncio support.

I would like to point the following:

• asyncio interface is also important for snowflake, so usability or applicability of that should be a no brainer
• all modern databases have async interfaces and they will only expand with time
• streamlit is based on asyncio itself, so at least properly exposing the original tornado's event loop would also not require to much work for you

Known problems for now:

• when using asyncio.run() -> RuntimeError: Event loop is closed if the requests follow concurrently in the tornado eventlets
• every eventlet with own event loop -> tasks are getting to the wrong event loop
• cached event loop for all eventlets through session state -> best for now, gets event loop is closed when multile sessions are acessing the app simultaneously

So with that said, very ugly workaround that I found working best for now:

@st.cache_resource(show_spinner=False)
def get_event_loop():
    loop = asyncio.new_event_loop()
    asyncio.set_event_loop(loop)
    return loop

if not st.session_state.get("event_loop"):
    st.session_state["event_loop"] = get_event_loop()

then pass that event loop wherever your data is coming from, here is motor example:

async def setup_db(force=False):
    if force or not st.session_state.get("db_client"):
        with st.spinner("Loading..."):
            client = AsyncIOMotorClient(
                os.environ["MONGODB_URI"],
                tls=MONGODB_TLS,
                io_loop=st.session_state["event_loop"],
            )
            st.session_state["db_client"] = await init_database(client=client)
            return client

init_database is a call to beanie's init database

I understand that making the entire framework async would require too much work and would prb confuse the ML/AI crowd too much, but streamlit is such a gorgeous framework, the only place it fails in misery is the async

Why?

Asyncio data technologies should be natively or at least easily accessible from streamlit apps.

How?

Runs with asyncio.run() should not result to errors. Concurrent access also should not be broken. Asyncio loop from tornado app should be available in the scripts.

Handling st.* calls async seems quite unimaginable, but at least the functioning asyncio in the eventlets would give us a lot.

Also async support for on_change and on_click callbacks and caching functions.

Additional Context

No response

[github-actions[bot]]

To help Streamlit prioritize this feature, react with a 👍 (thumbs up emoji) to the initial post.

Your vote helps us identify which enhancements matter most to our users.

[vikyw89]

2024 and no async support... yet, gonna thumbs this up 10 times

[mescanne]

Hello -

Just a bit of experimentation around Streamlit, threads, and asyncio.

My understanding:

• Every time a re-render is required (state change, user interaction, etc), a new thread is created and the script is run fresh. The old thread, if it hasn't already completed the script, may keep going (due to fastRerun) but any interaction with st objects will throw a Shutdown Exception.
• Streamlit does not care about asyncio, rather only if the thread has terminated or not.

I'm not sure how scalable this is -- threads will be active for each user potentially -- but my approach has been:

• Use asyncio.run() at the end of the script. This will create a new event loop for the thread (and render).
• The asyncio loop has tasks, which may run forever, must frequently interact with st (e.g. st.session_state) to trigger potential Shutdown exceptions to clean up the threads.
• If the asyncio loop ends early, then the "Running" indicator stops. So you can see the thread is still busy.

I haven't done scaled testing, but this approach seems to be working sensibly in my tests.