User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061026 BonEcho/2.0 Build Identifier: when you move lots of small files into a subfolder by drag and drop, the gui is not accessible until the task is done. Reproducible: Always Steps to Reproduce: 1. have about 900 small files (in my testcase i hade 880 image files) and a folder 2. select all the files and move them into the folder by drag and drop 3. shade the window and unshade it right after you released the mousebutton to start moving the files Actual Results: the gui is unresponsive for about 6 seconds (on a p4 3ghz with 1gb ram) while moving the files into the folder. Expected Results: i expect the files to be moved instantly with the gui staying responsive or a maybe show progress dialog but the gui should still be accessible.
Created attachment 870 First try
Created attachment 871 First attempt to address this issue I doubt that it fixes the problem, but I've no clue right now whats blocking the UI exactly.
hm that patch indeed doesn't fix the problem.
We have the same problem on our distribution with only one file. But we are using a customized FUSE which sometimes can take a long time to respond (because information is pulled from a server). As long as the file system calls have not returned, Thunar and XFCE are totally unresponsive. Sometimes, I can see "collecting file" window, sometimes I don't. I also was able to reproduce once this problem with smbnetfs which is another FUSE for neighborhood. Moving some files temporarely froze the system for a few seconds. My analysis is that Thunar does a collection of files info before moving them and as long as the file system calls have not returned, Thunar "freezes" the whole system. It's really a P1 for us and we are about to release our distribution. We would appreciate some help on this front.
Today I checked the Thunar code that starts the IO jobs and it looks the problem is that the system call to move the file(s) is blocking and it is not interruptible. Testing the case where the move takes sometime to complete (like Grégoire mentioned above), I simply replace the g_rename() with a sleep(20) to see if the GUI was responsive after all. In this case, the GUI is completely responsive, and I think the explanation is that the threads are preemptible in this case. To the extent of my tests, I couldn't find any lock problem. You can stop thread scheduling in gdb and run each one of these threads separately during the rename that it works fine. In particular, if you run the thread 1 (running the main loop), the gui is perfectly responsive as well (even with the IO thread totally stopped). There is no pre-processing, as we may think initially. It actually freezes only at the time the g_rename() (wrapper to the rename system call) is called. No other thread is run until the thread started for the move job finishes this system call. The main context thread stops completely and no part of the main event loop seems to run. Like the lock, I couldn't find anything in the way the jobs are launched that could be generate this problem. The creation of a thread pool for a job, starting a thread to handle it and all the signals seem to be working as expected. In case the problem is indeed that the system call is blocking the thread (and its preemption), would you have any idea of how to solve it, Benny? Maybe spawning another process to run the command?
We found out that FUSE has a locking problem when are performing a write operation. Other operations that require a read-only lock, like mkdir, create, open, read, write, etc, are blocked until the write lock is released. It can even be reproducible in the login console, what proves that it's not X or XFCE related. Commenting out these write locks (for testing purposes) makes these options to work concurrently and xfce in general turns out to be more responsive. It still not clear if this is the only problem, but definitely that's the major issue so far. As soon as we make more progress, we will update this report.
With GIO we do some nice threading stuff. Please reopen if this is still an issue with the latest Thunar release.