Community
Participate
Working Groups
I tried to install a feature with install handlers and in the process of launching the old Update Manager the entire UI thread was blocked.
Blocked as in never comes back, or just blocked for some non-trivial time? What build?
(In reply to comment #1) > Blocked as in never comes back, or just blocked for some non-trivial time? What > build? Blocked as in the UI thread is busy. Sorry, should have been more clear. I20090309-0800 upgraded to I20090310-0100.
I tried using the site in the test plan http://www.developer.com/img/2007/03/upd-install-site.xml and was able to successfully install using UM without a hang. I was working on WinXP with a I20090309-1300 that had been upgraded to I20090310-0100. Which site were you using? If it was the site above, did you see the "Splash!" bitmap come up during the install? I'm wondering if the handler itself hung...
(In reply to comment #3) > I tried using the site in the test plan > http://www.developer.com/img/2007/03/upd-install-site.xml > and was able to successfully install using UM without a hang. > > I was working on WinXP with a I20090309-1300 that had been upgraded to > I20090310-0100. > > Which site were you using? > If it was the site above, did you see the "Splash!" bitmap come up during the > install? > > I'm wondering if the handler itself hung... I didn't actually go through with the install. I was just trying to point out that the launching of the old UM seemed to be done in the UI thread.
Well, yes, the UM wizard is launched from the p2 wizard, so it's in the UI thread. So you get a modal UM wizard which is parented by a modal p2 wizard. I don't see that this is a huge problem, or are you saying the UI thread seemed blocked (ie, no paints, no updating, something more serious than a modal dialog?) DJ, did you observe anything funky here on Linux?
(In reply to comment #5) > I don't see that this is a huge problem, or are you saying the UI thread seemed > blocked (ie, no paints, no updating, something more serious than a modal > dialog?) Yes, no paints, no updating, etc.
I think the problem is that the very first time update is touched, update.configurator does a bunch of work (see also bug 266236). ui.ide used to start update during its startup, but they have recently been cleaning up references to update so it may no longer be happening. So, it may just be that this was the first contact with update and it is initializing.
(In reply to comment #5) > Well, yes, the UM wizard is launched from the p2 wizard, so it's in the UI > thread. So you get a modal UM wizard which is parented by a modal p2 wizard. > I don't see that this is a huge problem, or are you saying the UI thread seemed > blocked (ie, no paints, no updating, something more serious than a modal > dialog?) > > DJ, did you observe anything funky here on Linux? > I see the same behaviour as Andrew... no paints until the UM dialog comes up.
I'll mark this for the 3.5 polish list, but I'm not sure if I can fix this outside of UM. I'll examine starting UM up in a job and then invoking the UI (just don't know if there's API for that)...
I don't think there is much we can do about this. There is a non-trival hit when the update bundles are first started. This might happen here, or it might happen elsewhere. We could play tricks with manually starting the update bundles in the background prior to invoking the update UI, but this is getting quite fancy for a backward compatibility layer. People will be steadily migrating away from UM install handlers towards p2 touchpoints so this issue will become even less interesting in the future. Consider it just one more bit of incentive for people to migrate their sites/features away from UM install handlers.
