Is it possible to have the TASK monitor also show VFS tasks, so we can phase out the
I/O Progress Monitor?
| Submitted | ezust - 2011-10-08 - 22:27:41z | Assigned | thomasmey |
|---|---|---|---|
| Priority | 5 | Category | core |
| Status | Open | Group | None |
| Resolution | Remind | Visibility | No |
| 2011-10-17 - 16:37:17z kpouer |
Done, in fact it is now included in the Task Monitor |
|---|---|
| 2011-10-17 - 17:29:18z ezust |
Well, you took the two panels and snapped them together into a single dockable, which
is an improvement over how it was before (now there is only one place to check), but
I imagined a more integrated approach, where individual i/o progress items would be
shown as individual tasks in the task monitor. That is, each time something is created
and shown in the I/O progress space, create a corresponding task and show that. This way there would be less space needed for the dockable also. I am having trouble finding long-running i/o progress jobs at the moment to test this on. |
| 2011-10-17 - 17:57:23z kpouer |
Yes I understand that, but the concept is different. Task Monitor is a queue, and IO Progress Monitor show threads. So IO Progress Monitor always show the same number of progress bar and the Task Monitor show all tasks waiting for execution. I think rewriting this entirely is not a priority because the goal is to remove the old threadpool completely |
| 2011-10-20 - 16:02:12z ezust |
Is there another ticket for that? |
| 2011-10-21 - 16:40:35z kpouer |
About removing the old threadpool completely ? |
| 2011-10-21 - 16:41:39z ezust |
Yes, removing the old threadpool, rewriting the VFS so it uses the task monitor instead
of the old API. If there is no other ticket, let's use this one to track it. |
| 2012-08-11 - 16:50:03z thomasmey |
There is some strange serialisation going on between the submitted AWT "tasks" and
the "background tasks". Please have a look at my attached patch. It converts WorkRequest to be more similar to Task. |
| 2012-08-12 - 10:48:51z thomasmey |
VFSFileChooserDialog submits a Runnable to background queue which is not an instance of WorkRequest. This happens while you try to save a file. Fixed patch attached. |
| 2012-08-12 - 12:46:52z jarekczek |
Thomas, please submit patches ONLY |
| 2012-08-12 - 12:47:10z jarekczek |
... as separate tickets. |
| 2012-08-12 - 15:45:10z thomasmey |
Okay, will do so tomorrow. I'm a bit in a hurry right now. I'll attach step 2 here, which converts the intermediate state to use the Task api. |
| 2012-08-13 - 13:55:26z kpouer |
Thomas, embedding WorkRequest in Task is not as easy as it seems. In the old threadpool the AWT tasks were queued after background tasks. If you were doing several runInWorkThread() calls and runInAWTThread() the AWT requests were done after all WorkThread have finish their work. It was convenient but not very efficient. Replacing all runInWorkThread() by calls to the new threadpool and all runInAWTThread by EventQueue.invokeLater() is not an option because it would cause many bugs. But reproducing the same behavior with the new threadpool is also not a good idea because the goal was to change that to remove those freezing problems. I didn't read your patch but tried to apply it, and it fails. Also in your patch item in the tracker, if you update your patch, you should remove the old one so it is easier to understand what must be applied and what must not. |
| 2012-08-13 - 15:51:45z thomasmey |
Hi, yes sorry for the error. I forget to add the WorkThreadFactory class to the Mercurial MQ... See Patch tracker https://sourceforge.net/tracker/?func=detail&aid=3556968&group_id=588&atid=300588 for the first conversion step. This new patch should apply cleanly. I'll polish the second step which converts all WorkRequest class users to Task and introduces an ioTask List in the TaskManager to serialize AWT tasks via this List. |
| 2012-09-01 - 19:19:15z ezust |
Assigning to Thomas Meyer who seems to have just about fixed it. |