os: windows server 2012
pyautogui: 0.6.53
PyScreeze: 0.1.28
threads model:
at server startup, run flask app, force it's working thread number to be 1 (1st thread), and ensure no coming requests during the whole experiment.
at server startup, start a new thread(2nd) to periodically call a refresh myself rpc with a high frequence(~1 time/s) to etcd, to let upstream servers find me.
at server startup, start a new thread(3rd) to periodically input something, in a text editor.
Found that, each time when keyboard input something, it will cause the rpcs in the 2nd thread to got a long response time even timeout, only after inputting job done the rpc could back to normal.
I'm wondering if the 2nd (network rpc) & 3rd thread (keyboard input) are sharing some lock under the hood, searched and found windows essentially shouldn't have such mechanisms.
os: windows server 2012 pyautogui: 0.6.53 PyScreeze: 0.1.28
threads model:
Found that, each time when keyboard input something, it will cause the rpcs in the 2nd thread to got a long response time even timeout, only after inputting job done the rpc could back to normal.
I'm wondering if the 2nd (network rpc) & 3rd thread (keyboard input) are sharing some lock under the hood, searched and found windows essentially shouldn't have such mechanisms.
Any suggestions on this? thx