On Jun 25, 2009, at 7:20 AM, Michal Pryc wrote:
Tom Mueller wrote:
johan...@sun.com wrote:
The transport uses a single libcurl multi-handle, which means that
if
multiple threads are going to use the transport, we have to
serialize
callers of multi_perform() for our handle. All of the client is
single
threaded, and I haven't seen any documentation from the GUI team
outlining a multi-threaded approach to downloading.
Do you mean a single one for all images, or one per image? (Sorry,
I haven't had a chance to review the code yet).
The updatetool GUI currently uses multi-threading for evaluating
update plans for multiple user images simultaneously.
Could this at least be done at the image level to allow this?
I have double checked this and it looks like the background thread
for getting package descriptions is causing the problem.
What is currently happening, when the user is starting PM, the
background thread is fired to get descriptions for the packages.
This is going to change, so when the user is scrolling to some set
of packages, the descriptions are being gathered for the visible
rows only. Also when the user performs search, for the visible rows
descriptions are being downloaded.
At the same time the packae may be installed. So when the
description thread is not yet finished and the user will try to
install package this problem will occur. Also when the user clicks
on the license tab, sometimes it takes ~3 seconds to download the
license. During this time if I will hit install button, this error
will occur.
One solution would be to add the lock mechanism in the GUI, but I am
not sure if this would be better solution then adding such mechanism
in the api itself. There is already lock mechanism in the api for
other purposes.
While it makes sense for the transport layer to have a lock, shouldn't
the GUI not bother attempting to perform these operations given that
modal nature of the install/update dialogs and to avoid the
unnecessary overhead of a waiting background thread?
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
