| WorkspaceCatchUpJob blocks UI [message #486597] |
Fri, 18 September 2009 11:07  |
 Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi,
I'm having fairly complex workspaces (comparable in size to the
buckminster project) and what always annoyed me is that Buckminster ->
invoke action freezes the UI for about 30 seconds on first usage.
Since I already provided a new invoke action dialog that is perfectly
suited for long running background operations with proper progress
information, I decided to write a patch so this dialog won't freeze the
UI anymore.
While this is no problem to do (I can offer a patch this weekend if
you're interested), I had to notice some rather odd things about the
current implementation. I'd like to ask about these code pieces, since I
think fixing the dialog will solve my problem at hand, but does not fix
the root of the problem.
Ok, so what happens? The AbstractCSpecAction tries to retrieve a CSpec
for the current selection in selectionChanged:
m_selectedComponent = (CSpec)((IAdaptable)first).getAdapter(CSpec.class);
This will end up in WorkspaceInfo in these two methods:
private static void checkFirstUse()
{
// We want the first caller to star the job. That job in turn will
// result in recursive calls that should return immediately.
//
synchronized(WorkspaceInfo.class)
{
if(s_hasBeenActivated)
return;
s_hasBeenActivated = true;
}
runWorkspaceCatchUpJob();
}
public static void runWorkspaceCatchUpJob()
{
WorkspaceCatchUpJob catchUpJob = new WorkspaceCatchUpJob();
catchUpJob.schedule();
try
{
catchUpJob.join();
}
catch(InterruptedException e)
{
}
}
As you can see, the first caller will trigger the job and will join the
job. In other words, the call for the CSpec Adapter will not return
until the WorkspaceCatchUpJob is completed and this is what freezes the UI.
However, as you can see, only the first caller joins the job, if another
thread calls methods in WorkspaceInfo while the job is still running,
these calls wil return immediatly. Why is that so and is that really the
intention?
To verify this, I changed the AbstractCSpecAction#selectionChanged a little:
if(first instanceof IAdaptable)
{
new Thread(new Runnable()
{
public void run()
{
((IAdaptable)first).getAdapter(CSpec.class);
System.out.println("done in background thread");
}
}).start();
try
{
Thread.sleep(1000);
}
catch(InterruptedException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
m_selectedComponent = (CSpec)((IAdaptable)first).getAdapter(CSpec.class);
System.out.println("done in UI thread");
}
So a background thread first tries to fetch the CSpec and then the UI
thread tries the same. The result is (for non-trivial workspaces) always:
done in UI thread
done in background thread (a lot later)
Surprisingly enough this shows the InvokeActionDialog correctly and
significantly faster, even though the WorkspaceCatchUpJob did not complete.
So the next question: are there scenarios where the job has to be
completed before all attributes of the choosen CSpec become available,
or would it actually work without waiting for completion of the job?
If such scenarios exist, should I just fix the Dialog +
AbstractCSpecAction in a way that the blocking call does not happen in
the UI thread and the dialog can properly display progress, or should I
also fix that every call to WorkspaceInfo will be blocking until the job
is completed?
Best regards,
Johannes
|
|
|
|
| Re: WorkspaceCatchUpJob blocks UI [message #486610 is a reply to message #486601] |
Fri, 18 September 2009 11:30  |
|
Hi Johannes,
I've noticed this too and made the same conclusion. So a patch would be very appreciated. The
partial results must be investigated of course. That's never OK.
Regards,
Thomas Hallgren
Johannes Utzig wrote:
> ok, some further testing revealed that the job indeed needs to finish
> before there are reliable results.
> I would therefore like to change the behaviour of the Dialog and the
> AbstractCSpecAction so they are no longer freezing the UI.
> If that's ok with you, I'd like to create a bug and submit a patch
> during the weekend.
>
> However, it still seems strange to me that the first caller gets
> blocked, while subsequent callers to WorkspaceInfo return immediatly
> with potentially partial results....
>
>
> Best regards,
> Johannes
|
|
|
| Re: WorkspaceCatchUpJob blocks UI [message #486611 is a reply to message #486610] |
Fri, 18 September 2009 11:52 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas,
ok, I will focus only on the UI part then since this won't impact other
parts of the system. I'll work on this after work and submit my results
to bugzilla so you can review the approach.
I was planning to assign the job to a job-family so clients (like the
action) may wait for the job by using the job-manager. Once the job has
a family, the same approach can then be used to have all callers of
WorkspaceInfo wait for the job while its running and that would solve
the threading issues with the current implementation. That's just one
possible approach of course...
Best regards,
Johannes
Thomas Hallgren schrieb:
> Hi Johannes,
> I've noticed this too and made the same conclusion. So a patch would be
> very appreciated. The partial results must be investigated of course.
> That's never OK.
>
> Regards,
> Thomas Hallgren
>
> Johannes Utzig wrote:
>> ok, some further testing revealed that the job indeed needs to finish
>> before there are reliable results.
>> I would therefore like to change the behaviour of the Dialog and the
>> AbstractCSpecAction so they are no longer freezing the UI.
>> If that's ok with you, I'd like to create a bug and submit a patch
>> during the weekend.
>>
>> However, it still seems strange to me that the first caller gets
>> blocked, while subsequent callers to WorkspaceInfo return immediatly
>> with potentially partial results....
>>
>>
>> Best regards,
>> Johannes
|
|
|
Powered by
FUDForum. Page generated in 0.03209 seconds
] 
Search
Help
Register
Login
Home
