[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] Mutex waitForLock() updates the progress monitor
|
Hi Patrick,
this is 100% intended behavior.
When the lock is busy, your task needs to wait. Users want
visual feedback during that time in
order to see that something still happens.
As a client, you are responsible for proper scaling, so yes
if the units of work don't fit you
then you need to create a
SubProgressMonitor.
The only room for improvement I see here is that it would
be nice to configure the amount
of time we wait for the lock to become
available.
Or am I missing anything?
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
When I call some of the public method from SftpFileService and
provide an IProgressMonitor, waitForLock() might be called on the
fDirChannelMutex (instance of org.eclipse.rse.services.Mutex).
If the
lock is busy, every second 1 unit of work is applied to the progress monitor.
It looks like progress is being made on my main task, but after 5 units of
work (in my case reaching 100% completion), the operation might fail with a
SystemLockTimeoutException.
Is this the intended behavior? It forces
the user of the API to create a new progress monitor for those tasks using
SftpFileService. I expected that I could just provide my top-level progress
monitor to allow for cancellation of the whole task during
waitForLock().
Thanks,
Patrick
