| WorkbenchJob vs Display.synchExecute [message #283452] |
Sat, 02 April 2005 13:35  |
Eclipse User |
|
|
|
Originally posted by: dfayerma.wyeth.com
What is the recommended way to perform operation in the UI thread from a background job?
I have a Job running in the background thread that needs to access UI elements.
Looking in the platform source code, I see that most of the time this is acomplished by creating
a WorkbenchJob, implementing it's runInUIThread method and marking this job as system.
Since I need to wait for the result, I would also call join method on it.
What is the advantage of using the WorkbenchJob vs Display.synchExecute. If the job is system, the status is not displayed any way.
It looks like WorkbenchJob with join is slower then using synchExecute.
Thanks.
Dimitry Fayerman
|
|
|
| Re: WorkbenchJob vs Display.synchExecute [message #283462 is a reply to message #283452] |
Sun, 03 April 2005 15:46  |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Dimitry Fayerman wrote:
> What is the recommended way to perform operation in the UI thread from a background job?
>
> I have a Job running in the background thread that needs to access UI elements.
>
> Looking in the platform source code, I see that most of the time this is acomplished by creating
> a WorkbenchJob, implementing it's runInUIThread method and marking this job as system.
> Since I need to wait for the result, I would also call join method on it.
>
> What is the advantage of using the WorkbenchJob vs Display.synchExecute. If the job is system, the status is not displayed any way.
>
> It looks like WorkbenchJob with join is slower then using synchExecute.
>
> Thanks.
> Dimitry Fayerman
If you need to wait for the result I wouldn't call it a 'job.' How are
you both running in the background & waiting on the result?
CL
|
|
|
| Re: WorkbenchJob vs Display.synchExecute [message #283474 is a reply to message #283462] |
Sun, 03 April 2005 21:03 |
| Eclipse User |
|
|
|
Originally posted by: dfayerma.wyeth.com
>If you need to wait for the result I wouldn't call it a 'job.' How are
>you both running in the background & waiting on the result?
I'm loading data into the tree in the background. The job loads data in chunks. It has a loop that prepares a packet to be loaded (may take some time),
then synchronously adds it to the tree in the UI thread, prepares next packet in the background thread, etc. until all packets are done.
The question was not if I need the background thread but rather if I need to execute something in UI thread, what is the advantage of using WorkbenchJob with system flag vs. Display.synchExecute.
Thanks.
Dimitry.
|
|
|
| Re: WorkbenchJob vs Display.synchExecute [message #283485 is a reply to message #283474] |
Mon, 04 April 2005 03:15 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Dimitry Fayerman wrote:
>>If you need to wait for the result I wouldn't call it a 'job.' How are
>>you both running in the background & waiting on the result?
>
>
>
> I'm loading data into the tree in the background. The job loads data in chunks. It has a loop that prepares a packet to be loaded (may take some time),
> then synchronously adds it to the tree in the UI thread, prepares next packet in the background thread, etc. until all packets are done.
>
> The question was not if I need the background thread but rather if I need to execute something in UI thread, what is the advantage of using WorkbenchJob with system flag vs. Display.synchExecute.
>
> Thanks.
> Dimitry.
The question of the background thread is intimately involved in these
two methods. A Job is inherently a background thing, whereas
Display.syncExec and Display.asyncExec are not.
A job is 'scheduled' and supports rules which can prevent other jobs
from conflicting with them. The job architecture is here to support the
idea of 'resources' so that a job can use a resource and other jobs can
not use it while it is buys. Display.asyncexec does not have any such
notion. Display is the raw stuff that gets you into the UI thread. the
Jobs will call Display when they are ready to run in the UI thread as well.
For your case since you have a master thread managing these background
'jobs' I dont see why you need a UI job. the UI is handled by your
master thread when the data comes back from each job. in this case, as
the data comes in, just call Display.asyncexec() to update your tree.
it dont make sense to send out another job whose sole purpose would be
to update the tree. nor does it make sense to use a workbenchjob in the
first place as the whole job would be run in the ui and would halt the
whole ui while it ran. Perhaps a regular Job with a Display.asyncExec()
on the tail end of it...
For my trees I use DeferredTreeContentManager. It works nicely by
putting placeholders in the tree and other stuff while the actual data
is loaded as needed in the background. You gotta use a
IDeferredWorkbenchAdapter on your Nodes probably though. you can likely
find some examples in the eclipse source and see if it fits yoru needs.
probably this deferred stuff uses a regular Job with a sprinkly of
Display.asyncexec on the end of it.
CL
|
|
|
| Re: WorkbenchJob vs Display.synchExecute [message #283501 is a reply to message #283485] |
Mon, 04 April 2005 15:52 |
| Eclipse User |
|
|
|
Originally posted by: dfayerma.wyeth.com
The DeferredTreeContentManager is exactly where I started with. The fundamental problem with this class as with most of IDE views and editors is that they expect your domain objects to implement IDeferredWorkbenchAdapter or at least IAdaptable.
I think it is absolutely unacceptable for Domain objects to have to implement UI specific interfaces. Especially for a non IDE RCP application.
It also goes against the whole MVC pattern with content presentation decisions separated in content and label providers.
I will post an enhancement request about in on the bugzilla.
In addition the IDeferredWorkbenchAdapter is not well encapsulated and is not generic enough to be used with any content provider.
I created a DeferrredTreeContentProvider that wraps a regular content passed in the constructor adding the asycn loading feature to it.
I think it is much easier to use and does not add any unnecessary requirements to your domain objects or your content provider.
When looking for implementations using DeferredTreeContentManager I found only the CVS view.
In addition to using the main background Job for deferring loading, it is using UI system jobs to asynchronously add items to the tree.
The problem is that if number of items to be added to the tree is big, loading Job finishes before the items are actually added to the tree by the UI thread.
I think it is better to keep the job running until all items are added so that there is visual indication to the user.
Thanks.
Dimitry Fayerman
>>> CL [dnoyeb] Gilbert<Lamont_Gilbert@rigidsoftware.com> 4/3/2005 11:15:47 PM >>>
Dimitry Fayerman wrote:
>>If you need to wait for the result I wouldn't call it a 'job.' How are
>>you both running in the background & waiting on the result?
>
>
>
> I'm loading data into the tree in the background. The job loads data in chunks. It has a loop that prepares a packet to be loaded (may take some time),
> then synchronously adds it to the tree in the UI thread, prepares next packet in the background thread, etc. until all packets are done.
>
> The question was not if I need the background thread but rather if I need to execute something in UI thread, what is the advantage of using WorkbenchJob with system flag vs. Display.synchExecute.
>
> Thanks.
> Dimitry.
The question of the background thread is intimately involved in these
two methods. A Job is inherently a background thing, whereas
Display.syncExec and Display.asyncExec are not.
A job is 'scheduled' and supports rules which can prevent other jobs
from conflicting with them. The job architecture is here to support the
idea of 'resources' so that a job can use a resource and other jobs can
not use it while it is buys. Display.asyncexec does not have any such
notion. Display is the raw stuff that gets you into the UI thread. the
Jobs will call Display when they are ready to run in the UI thread as well.
For your case since you have a master thread managing these background
'jobs' I dont see why you need a UI job. the UI is handled by your
master thread when the data comes back from each job. in this case, as
the data comes in, just call Display.asyncexec() to update your tree.
it dont make sense to send out another job whose sole purpose would be
to update the tree. nor does it make sense to use a workbenchjob in the
first place as the whole job would be run in the ui and would halt the
whole ui while it ran. Perhaps a regular Job with a Display.asyncExec()
on the tail end of it...
For my trees I use DeferredTreeContentManager. It works nicely by
putting placeholders in the tree and other stuff while the actual data
is loaded as needed in the background. You gotta use a
IDeferredWorkbenchAdapter on your Nodes probably though. you can likely
find some examples in the eclipse source and see if it fits yoru needs.
probably this deferred stuff uses a regular Job with a sprinkly of
Display.asyncexec on the end of it.
CL
|
|
|
| Re: WorkbenchJob vs Display.synchExecute [message #283512 is a reply to message #283501] |
Mon, 04 April 2005 20:57 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Dimitry Fayerman wrote:
> The DeferredTreeContentManager is exactly where I started with. The
> fundamental problem with this class as with most of IDE views and
> editors is that they expect your domain objects to implement
> IDeferredWorkbenchAdapter or at least IAdaptable. I think it is
> absolutely unacceptable for Domain objects to have to implement UI
> specific interfaces. Especially for a non IDE RCP application.
>
> It also goes against the whole MVC pattern with content presentation
> decisions separated in content and label providers.
>
> I will post an enhancement request about in on the bugzilla.
>
You dont have to expose your domain object like that. My Node only uses
my model object, but is not the object itself. Its was easy to add an
inner class that wraps the necessary calls to my model and exposes
itself as IDeferredWorkbenchAdapter.
This is a common technique that needs to be used throughout eclipse. I
have inner classes that wrap my model all over the place. I can't think
of any other way.
> In addition the IDeferredWorkbenchAdapter is not well encapsulated
> and is not generic enough to be used with any content provider. I
> created a DeferrredTreeContentProvider that wraps a regular content
> passed in the constructor adding the asycn loading feature to it. I
> think it is much easier to use and does not add any unnecessary
> requirements to your domain objects or your content provider.
>
I wrapped my model object in the IDeferredWorkBenchAdapter and
implemented the methods. I did not create my own
deferredTreeContentProvider, I just used a DeferredTreeContentManager
with my existing content provider. It has worked out well. i have not
modified any of my models to accomodate this. just used inner class
wrappers and stuff.
> When looking for implementations using DeferredTreeContentManager I
> found only the CVS view. In addition to using the main background Job
> for deferring loading, it is using UI system jobs to asynchronously
> add items to the tree.
>
Yes, I think the CVS was the one i mimiced.
> The problem is that if number of items to be added to the tree is
> big, loading Job finishes before the items are actually added to the
> tree by the UI thread.
>
hmm, dont fully know what you mean. If you got a lot of items, it just
wont add them all? that would be a bug I think.
> I think it is better to keep the job running until all items are
> added so that there is visual indication to the user.
>
> Thanks. Dimitry Fayerman
>
well the deferred system adds them as they are requested I believe. But
however you want to do it should work. I think you can use jobs to
process your data and Display.asyncexec to add your tree items.
Personall I would try to make the deferred system work as its obviously
there to solve the same problem. If it does not work for you put in a
bugzilla and I am sure they will accomodate you. Or you can accomodate
them :)
My objects are coming from a database so its noticeably slow. But I
didnt try large numbers of objects to see what happens yet..
Good luck,
CL
|
|
|
| Re: WorkbenchJob vs Display.synchExecute [message #283546 is a reply to message #283512] |
Tue, 05 April 2005 14:26 |
| Eclipse User |
|
|
|
Originally posted by: Michael_Valenta.oti.com
Dimitry,
Are you fetching items in response to a tree expansion or a user initiated
operation of some kind (e.g. a query). If it is in response to a tree
expansion, than DeferredTreeContentManager or a similar approach is
warranted (since that was the intended use of the class). For instance, this
is what the CVS Repositories view uses when the user expands a remote
folder. If the current support does not meet your needs, then, by all means,
enter a feature request. However, keep in mind that the chances of the
feature request being addressed in time to meet your needs is slim given the
amount of work the UI team has. A far more productive appoach would be to
refactor (or copy) the DeferredTreeContentManager and it's related
interfaces into a shape that does meet your needs and contribute it back to
the Eclipse UI component.
If you are fecthing items in reponse to another type of user operation, than
you should not be considering the use of the DeferredTreeContentManager.
Instead, you should consider having a background job that creates or
modifies a model that has no UI-ness about it (i.e. does not update the UI
at all but instead just manipulates model objects). You can than have a
separate job displays the current state of the model. This job can be
triggered to run at specific intervals while the background job is
manipulating the model in order for the user to see intermediate results.
You may need to use some sort of mutual exclusion mechanism (i.e. locks)
between the background job and the UI job to ensure that the model isn't
manipulated while the view is being updated. This is the sort of
architecture that is used to populate the Synchronize view in response to
CVS operations (sync, update, commit, etc.).
Michael
"CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in message
news:d2s9t1$nvt$1@news.eclipse.org...
> Dimitry Fayerman wrote:
>> The DeferredTreeContentManager is exactly where I started with. The
>> fundamental problem with this class as with most of IDE views and
>> editors is that they expect your domain objects to implement
>> IDeferredWorkbenchAdapter or at least IAdaptable. I think it is
>> absolutely unacceptable for Domain objects to have to implement UI
>> specific interfaces. Especially for a non IDE RCP application.
>>
>> It also goes against the whole MVC pattern with content presentation
>> decisions separated in content and label providers.
>>
>> I will post an enhancement request about in on the bugzilla.
>>
>
> You dont have to expose your domain object like that. My Node only uses
> my model object, but is not the object itself. Its was easy to add an
> inner class that wraps the necessary calls to my model and exposes itself
> as IDeferredWorkbenchAdapter.
>
> This is a common technique that needs to be used throughout eclipse. I
> have inner classes that wrap my model all over the place. I can't think
> of any other way.
>
>
>> In addition the IDeferredWorkbenchAdapter is not well encapsulated
>> and is not generic enough to be used with any content provider. I
>> created a DeferrredTreeContentProvider that wraps a regular content
>> passed in the constructor adding the asycn loading feature to it. I
>> think it is much easier to use and does not add any unnecessary
>> requirements to your domain objects or your content provider.
>>
>
> I wrapped my model object in the IDeferredWorkBenchAdapter and implemented
> the methods. I did not create my own deferredTreeContentProvider, I just
> used a DeferredTreeContentManager with my existing content provider. It
> has worked out well. i have not modified any of my models to accomodate
> this. just used inner class wrappers and stuff.
>
>
>> When looking for implementations using DeferredTreeContentManager I
>> found only the CVS view. In addition to using the main background Job
>> for deferring loading, it is using UI system jobs to asynchronously
>> add items to the tree.
>>
>
> Yes, I think the CVS was the one i mimiced.
>
>
>> The problem is that if number of items to be added to the tree is
>> big, loading Job finishes before the items are actually added to the
>> tree by the UI thread.
>>
>
> hmm, dont fully know what you mean. If you got a lot of items, it just
> wont add them all? that would be a bug I think.
>
>
>> I think it is better to keep the job running until all items are
>> added so that there is visual indication to the user.
>>
>> Thanks. Dimitry Fayerman
>>
>
> well the deferred system adds them as they are requested I believe. But
> however you want to do it should work. I think you can use jobs to
> process your data and Display.asyncexec to add your tree items.
>
> Personall I would try to make the deferred system work as its obviously
> there to solve the same problem. If it does not work for you put in a
> bugzilla and I am sure they will accomodate you. Or you can accomodate
> them :)
>
> My objects are coming from a database so its noticeably slow. But I didnt
> try large numbers of objects to see what happens yet..
>
>
> Good luck,
>
>
> CL
|
|
|
Powered by
FUDForum. Page generated in 0.03608 seconds
] 
Search
Help
Register
Login
Home
