[BUG] Interaction with Streamlit "Stop" button seems broken

[Prajval-1608]

While a for loop enclosed in stqdm is running, if you press the "Stop" button, in the top right corner of any Streamlit app, the code stops running (as expected) but then becomes non-functional. That is, if you try to again interact with the code, it misbehaves and doesn't do what is otherwise expected or .

To Reproduce

1. Enclose a long running for loop in stqdm.
2. Stop the execution using the "Stop" button in Streamlit (top right corner).
3. Try interacting with the code again.

Example :

from time import sleep
from stqdm import stqdm
import streamlit as st

submit = st.button('Click me')
if submit:
    for _ in stqdm(range(50)):
        sleep(0.5)

Expected behavior

The code should function exactly as it was functioning before pressing the "Stop" button.

The code doesn't behave as expected as shown in the below.

https://user-images.githubusercontent.com/89075634/191000722-d356a1d3-b2c6-4ac0-8e17-982ddb928f10.mp4

Desktop (please complete the following information):

• OS: Windows Version 21H2 Build 19044.1645
• Browser: Brave 1.43.93
• Streamlit version: 1.12.2
• STqdm veriosn: 0.0.4
• tqdm version: 4.64.1

[Wirg]

Hi @Prajval-1608,

Thanks for the detailed report.

I have been trying to reproduce the bug with the versions you provided and brave (instead of chrome or firefox). For weird reasons, I don't seem to have the issue.

Out of curiosity can you try to reproduce the same thing with this code :

from time import sleep
import streamlit as st

submit = st.button('Click me')
text_widget = st.empty()
progress_widget = st.empty()
if submit:
    for i in range(50):
        sleep(0.5)
        text_widget.write(i)
        progress_widget.progress(i / 50)

That would help me understand if it's stqdm / tqdm related or streamlit related and if it may be related to windows.

[Prajval-1608]

Hi @Wirg,

Thanks for replying. That's an interesting example. I ran the code provided by you on my personal machine and below is the result (I think it works as expected).

https://user-images.githubusercontent.com/89075634/191014740-b29e2c75-d347-4789-9864-892eb670d4e0.mp4

Also, I ran my code (the one in the original post) and tried it in Microsoft Edge and it still didn't work. So, I think we can eliminate the issue being due to the browser.

Also, I have access to a Linux server with the following details (I am not very aware of how Linux systems are versioned, please pardon me for that), NAME="Ubuntu" VERSION="20.04.3 LTS (Focal Fossa)" Python Version: 3.8.10 Streamlit Version: 1.12.2 STqdm Version: 0.0.4 tqdm Version: 4.64.1

So I tried running my code in this server, and to my surprise even I wasn't able to reproduce the error. It was functioning as expected. The 'click me' button along with stqdm progress bar works perfectly fine even after pressing the stop button.

I know I changed two variables (python version and OS) but I hope it helps you pinpoint the source of the issue.

[Wirg]

Hi @Prajval-1608 ,

Thanks a lot, we may be missing some informations, but I would bet around something going on with a tqdm / streamlit / windows combo. I am going to try working on a windows test later.

[Wirg]

Hi @Prajval-1608 ,

Sorry for the late response. I took time to investigate this one. It's due to tqdm lock to protect writing.

From my understanding, it appears only on windows when the project is existing with stop. I don't have a full fix right now appart from removing the lock which seems to matter only for writing to console or log file and in our case if multiple person use the backend=True options with multiple sessions at the same time.

You can simply override the lock by using :

from threading import RLock
from stqdm import stqdm

stqdm.set_lock(RLock())

Tell me if it helps and if I can close ?

[Prajval-1608]

Hi @Wirg,

Thanks for getting back on this. Yes, I can confirm that the workaround you provided works for me (on a Windows machine). You can close this issue now.

On a side note, I faced a similar contrast between Windows and Ubuntu machines recently. If you try to log to a single file via multiple processes, using python multiprocessing library, on a Ubuntu machine you can do it straight away without any issues. However, that isn't the case for a windows machine. In windows, you have to ensure every process sends all the log records to a multiprocess queue instance and set up a separate listener process/thread that reads the records from that queue and writes them to the log file. Probably, again something to do with how locks behave differently in the two OS.