| The JobManager's lock question [message #532072] |
Fri, 07 May 2010 00:59  |
Eclipse User |
|
|
|
I run a test that using the Job, and I find that when mutil user will wait for the JobManger's global lock, and so the UIThread is blocked, so can I change the JobManager's source to extend SessionSingletonBase, and in this case, means one user one JobManager's lock, so mutil user will not wait the global lock.
Is this solution will resolve the mutil user wait for lock's problem?
|
|
|
| Re: The JobManager's lock question [message #532126 is a reply to message #532072] |
Fri, 07 May 2010 05:11  |
| Eclipse User |
|
|
|
we recently solved this bug:
283490: Display.syncExec() leads to deadlock
https://bugs.eclipse.org/bugs/show_bug.cgi?id=283490
With these changes, the described problem shouldn't occur any more. If
you still experience problems, please file a bugzilla with standalone
code to reproduce.
BTW, making the JobManager a session-singleton would make Jobs that are
session-independent impossible and hence isn't an option.
Regards,
Rüdiger
--
Rüdiger Herrmann
http://eclipsesource.com
On 07.05.2010 06:59, andijo wrote:
> I run a test that using the Job, and I find that when mutil user will
> wait for the JobManger's global lock, and so the UIThread is blocked, so
> can I change the JobManager's source to extend SessionSingletonBase, and
> in this case, means one user one JobManager's lock, so mutil user will
> not wait the global lock.
> Is this solution will resolve the mutil user wait for lock's problem?
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.06166 seconds
Home