I have an application that checks for files placed in a certain directory and then processes the files and waits for the next file. Yesterday we fixed a bug and set the program to work again. This morning when I checked the display said it was working on a file, but when I checked the CPU resources, it was at zero. It normally is at about 13% or close to 1 core. I clicked the mouse at random in the terminal running Julia, and seemingly jarred it back to life. Somewhat later it stalled again. Same thing but this time I noticed that it was a right click that jarred it back to life.
I updated from Julia 1.7.1 to 1.7.2. It seems to be working fine so far.
This is on a windows 10 computer.
Has anyone seen this type of behaviour before? Or any hints as to what might be at fault.
Julia doesn’t listen to mouse clicks,* so this seems just well an apparent random pause/slowness in your Julia program, and it would have continued without you doing anything. I suspect something like an anti-virus program interfering, especially on Windows, maybe something built-in. Your *own Julia program can listen to the mouse (even in the terminal, on Linux, Windows and macOS, I wasn’t sure possible, I confirmed in Python with “from pynput import mouse”), but if so you could or should know if it did.
There are some exceptions, like in Linux middle clicking might paste text, so it would look like input from the keyboard. Julia would also ignore such for your program, except maybe CTRL-C, unless your program were expecting input.
* I’m pretty sure about this, there’s no good reason for Julia or other languages, such as C++ (it neither has any mouse support in its standard library, nor seemingly Python), to do it (Visual Basic might be an exception), by default. I even checked the source code for Julia for “mouse” and I only found emoji/mouse false-alarms:
"\\:mouse:" => "🐭",
"\\:mouse_trap:" => "🪤",
FYI: If you DO want to listen to a mouse, there’s seemingly some Julia code available (or you could call Python with the the above mentioned library), so if you suspect your code doing that, you can look up if relevant Julia (or e.g. Python) packages used:
Perhaps something is pausing applications that do not have focus? Are you using a battery saver or something like that?
Thanks for the responses.
This program displays when it is processing a file, and when it is finished it displays that it has waited x seconds since processing the last file. While waiting it goes to sleep using the Julia sleep command. Every 15 s it checks for a new file. If the new file is there it displays that it is processing. If there is not a new file it redisplays the number of seconds it has been waiting and goes back to sleep. If I watch the CPU resources in the task manager I can confirm that it sleeping or processing.
During these anomalies, I was watching the CPU resources in the task manager while the program was in a state where it should have been processing a file. The CPU resources were 0 (or really close). Then with the right mouse click the CPU resources went to 13%. It seemed odd.
The program is essentially a continuous while loop that never terminates by itself. It either terminates with a Ctrl C or by exiting the terminal running the process. Either way a hard kill of the process. The Ctrl C also exits the terminal running the process, somewhat to my chagrin.
It is an industrial Lenova machine, no batteries. I believe it only has the Windows default anti-virus and firewalls. It is a headless machine. I access it by remote desktop connection to an intermediate virtual machine and then TightVNC to this remote machine. So I suppose it is possible that a right mouse click has opportunity to be something different on the remote machine?
Everything ran well after I posted yesterday.
So I gather it could be something weird happening in the communication between computers, a weird interaction between the OS and Julia, or perhaps even some weird hardware issue, or as suggested some very improbable random event.
This would have been good info from the start, likely explaining (in part, of fully because of TightVNC) the “pause”. Maybe you didn’t know this when posting. Also helpful::
I suspect there’s some optimization in your setup, likely by TightVNC, to save bandwidth, since these programs are likely made for use of more interactive programs (or with less sleeping). What I found for VNC may apply to it:
Try to use this:
-snapfb
[…]I had issues with update latency of 10secs +. This flag made this problem completely go away. Don’t know why this answer does not have more upvotes.