Home » Eclipse Projects » Eclipse Platform » Eclipse startup problem
| Eclipse startup problem [message #321485] |
Thu, 18 October 2007 07:01  |
Eclipse User |
|
|
|
Hi,
Since long I have had this problem which I avoided using different
techniques but it has come back to haunt me again and again. So I thought I
put it to rest once and for all. But the problem is I have no idea how to.
I have to load data associated with projects from files on startup. But if I
do this in a plugin start() method it can cause deadlocks as the loading
process can be long running. So as I understand for other threads to access
classes from a plugin its start method needs to finish quickly.
The solution I put for not holding the start method for long was to load
projects in a separte workspace job. This job can use the UI thread for user
interaction also sometimes. Now all my views, editors and property pages
depend on information that is loaded for projects. When loading in a
separate job I cannot make the UI thread wait for loading to finish. As I
have seen that the UI thread starts creating views and editors quite early
during startup and the workspace job runs quite late. If the UI thread is
made to wait for load job then a deadlock occurs because for some reason the
job (even when it got a chance to get scheduled) won't run unless the UI
thread is freed.
One solution that comes to my mind is that I use a call back and whenever
projects are loaded, the editors, views and pages update their GUI. But this
is not a good approach as it puts a restriction on the user of my interface
to check for loading and register a listener for callback.
I am sure this is a very common requirement, i.e. loading our own data for
projects at startup without causing deadlocks. There must be a good solution
or technique out there. I tried searching but unfortunately did not find any
thing.
Thanks in advance for any help.
Waqas
|
|
|
| Re: Eclipse startup problem [message #321492 is a reply to message #321485] |
Thu, 18 October 2007 07:49  |
| Eclipse User |
|
|
|
On 18/10/2007 13:01 Waqas Ilyas ha scritto:
> I am sure this is a very common requirement, i.e. loading our own data for
> projects at startup without causing deadlocks. There must be a good solution
> or technique out there. I tried searching but unfortunately did not find any
> thing.
One suggestion I can give you is to load the data when requested from
someone, and not when the plugin is activated.
For example, add a method in your plugin activator that loads the data
and returns only when the required things are loaded, then whenever you
need the data your code simply calls this method first, if the data is
already available is returns immediately, otherwise it waits.
Views that can't hold the UI can use a Job to call the load method, then
fire an update on the UI thread the the job is finished. Other objects
that don't care how long it takes can call the load method directly.
With the addition of some locking mechanisms (synchronized method,
JobManager locks, or others) on the load method, you should synchronize
all threads that are waiting for the data to load and avoid deadlocks
quite easily.
Hope this helps.
Regards,
Marco.
|
|
|
| Re: Eclipse startup problem [message #321497 is a reply to message #321492] |
Thu, 18 October 2007 08:49 |
| Eclipse User |
|
|
|
Thanks for the prompt reply.
Demand loading is a good option, I will think more about it. But the
problem with demand loading is that it can make UI lock for as long as data
is bieng loaded in the background. Even if I make the UI responsive, the
delays that a user experiences whenever, say, a selection is made in the
navigator can be troublesome (even though it won't happen again for the same
selection). But I am willing to use this as the last resort.
As I said in my email, I do not want to delegate the responsibility of
initiating teh load and refreshing UI to users of my code (in this case the
views, editors and property pages). So either I have to find a way to make
them wait (which in case of UI thread will definitely have deadlocks) or
load in the same thread as the calling method, no matter how long it takes
(demand loading in other words).
"Marco Maccaferri" <macca@maccasoft.com> wrote in message
news:ff7h7k$qgi$1@build.eclipse.org...
>
> On 18/10/2007 13:01 Waqas Ilyas ha scritto:
>
>> I am sure this is a very common requirement, i.e. loading our own data
>> for projects at startup without causing deadlocks. There must be a good
>> solution or technique out there. I tried searching but unfortunately did
>> not find any thing.
>
> One suggestion I can give you is to load the data when requested from
> someone, and not when the plugin is activated.
>
> For example, add a method in your plugin activator that loads the data and
> returns only when the required things are loaded, then whenever you need
> the data your code simply calls this method first, if the data is already
> available is returns immediately, otherwise it waits.
>
> Views that can't hold the UI can use a Job to call the load method, then
> fire an update on the UI thread the the job is finished. Other objects
> that don't care how long it takes can call the load method directly.
>
> With the addition of some locking mechanisms (synchronized method,
> JobManager locks, or others) on the load method, you should synchronize
> all threads that are waiting for the data to load and avoid deadlocks
> quite easily.
>
> Hope this helps.
>
> Regards,
> Marco.
|
|
|
| Re: Eclipse startup problem [message #321512 is a reply to message #321497] |
Thu, 18 October 2007 14:08 |
| Eclipse User |
|
|
|
On 18/10/2007 14:49 Waqas Ilyas ha scritto:
> Demand loading is a good option, I will think more about it. But the
> problem with demand loading is that it can make UI lock for as long as data
> is bieng loaded in the background.
I don't see much choices here, if the informations are available they
can be displayed immediately, otherwise the user must wait.
Maybe we mean different things with 'UI lock', the UI is not locked as
not being able to do anything else, but as the informations are not yet
available so the view displays a 'waiting' message and all controls on
that view are disabled, the UI thread is free to run, the loading thread
is blocked.
Consider for example Eclipse's team history view. When you request the
history of a file a background job is started, the view is blanked, the
title bar shows the 'busy' indication (italic font) and it is updated
when the background job is finished. You can do something else in the
meantime, open an editor, another view, etc., the UI is not locked.
You can do something similar, maybe display a 'please wait' message,
and, if the content must change with a selection, add some logic to
cancel the previous job, or avoid the update of obsolete data, if still
running.
> As I said in my email, I do not want to delegate the responsibility of
> initiating teh load and refreshing UI to users of my code (in this case the
> views, editors and property pages).
That's not exactly what I mean. The users do not intentionally initiate
the loading, it is an effect of requesting some data that is not yet
available.
> So either I have to find a way to make
> them wait (which in case of UI thread will definitely have deadlocks) or
> load in the same thread as the calling method, no matter how long it takes
> (demand loading in other words).
I'm not a good expert of the IDE Platform API, but you may take a look
at the project builders API (org.eclipse.core.resources.builders
extension point). If I understand you correctly, you need to add
something to projects (or other resources), maybe you can implement a
builder that loads the data you need in the background and fires updates
to the workspace resources. I can't give you more details on this as I
don't know this aspect much.
Regards,
Marco.
|
|
|
| Re: Eclipse startup problem [message #321527 is a reply to message #321512] |
Thu, 18 October 2007 23:45 |
| Eclipse User |
|
|
|
Thanks for all the help. I will start working on a solution and will reply
again if I run into problems.
Just one thing, when I said that I do not want to delegate the
responsibility to Views and editors I meant if I do load in a background job
and return some indication to the view that data is bieng loaded, then it
means (as I understand) that the view will have to not only request data but
also would be required to act accordingly if the data is not returned but
some indication that it is bieng loaded. The view will also have to register
some listener so that it can update itself when the data is finally
available.
In light of our discussion I think demand loading is the better solution.
Whenever data is requested no matter from what thread it will be loaded in
the same thread if not already loaded. So that the data get call always
returns the data, whether after loading or just getting loaded information.
"Marco Maccaferri" <macca@maccasoft.com> wrote in message
news:ff87eo$hs$1@build.eclipse.org...
>
> On 18/10/2007 14:49 Waqas Ilyas ha scritto:
>
>> Demand loading is a good option, I will think more about it. But the
>> problem with demand loading is that it can make UI lock for as long as
>> data is bieng loaded in the background.
>
> I don't see much choices here, if the informations are available they can
> be displayed immediately, otherwise the user must wait.
>
> Maybe we mean different things with 'UI lock', the UI is not locked as not
> being able to do anything else, but as the informations are not yet
> available so the view displays a 'waiting' message and all controls on
> that view are disabled, the UI thread is free to run, the loading thread
> is blocked.
>
> Consider for example Eclipse's team history view. When you request the
> history of a file a background job is started, the view is blanked, the
> title bar shows the 'busy' indication (italic font) and it is updated when
> the background job is finished. You can do something else in the meantime,
> open an editor, another view, etc., the UI is not locked.
>
> You can do something similar, maybe display a 'please wait' message, and,
> if the content must change with a selection, add some logic to cancel the
> previous job, or avoid the update of obsolete data, if still running.
>
>> As I said in my email, I do not want to delegate the responsibility of
>> initiating teh load and refreshing UI to users of my code (in this case
>> the views, editors and property pages).
>
> That's not exactly what I mean. The users do not intentionally initiate
> the loading, it is an effect of requesting some data that is not yet
> available.
>
>> So either I have to find a way to make them wait (which in case of UI
>> thread will definitely have deadlocks) or load in the same thread as the
>> calling method, no matter how long it takes (demand loading in other
>> words).
>
> I'm not a good expert of the IDE Platform API, but you may take a look at
> the project builders API (org.eclipse.core.resources.builders extension
> point). If I understand you correctly, you need to add something to
> projects (or other resources), maybe you can implement a builder that
> loads the data you need in the background and fires updates to the
> workspace resources. I can't give you more details on this as I don't know
> this aspect much.
>
> Regards,
> Marco.
|
|
|
Goto Forum:
Current Time: Sun Nov 09 18:36:03 EST 2025
Powered by FUDForum. Page generated in 0.23671 seconds |
Home