[news.eclipse.tools.emf] Re: EMF Transaction: Problems with InterruptedE

[Bernd Vogt <bernd.vogt@xxxxxxxxxxxxxx>]

Hi Christian,

I fear that there is no particular scenario in that the 
InterruptedException occures. But I belive that in the most cases there 
was a progress bar involved (e.g. a progress monitor dialog, or busy 
cursor or sth.). So my assumption is that there is a ModalContext doing 
sth. (e.g. code generation) and some viewer refreshes in the background.

I will strongly prefer the private non-throwing acquire call from the 
uiSafeAcquire(...) method... because when I have to teach my colleagues 
that they have to put their runExclusive calls into a loop repeating the 
call if it failes... I get stone to death... :-)

Best regards,
Bernd

Christian W. Damus wrote:
> Hi, Bernd,
>
> Yes, the Eclipse UI framework does frequently interrupt the UI thread, 
> and I'm not sure that it's a sound strategy (I had some discussion with 
> the Platform UI team about that a couple of years ago).
>
> In any case, the acquire methods are following the Java best-practice of 
> always checking for interrupted status at the beginning of an API call 
> that may block.  Perhaps the problem is that it isn't necessary to use 
> this external API in the re-entry scenario that you are seeing, but we 
> could use a private method that doesn't check for interrupt.
>
> I'm not sure that I would be comfortable with this, though, because any 
> call that may block can also be interrupted during that wait, and if the 
> interrupt status isn't first cleared, then a subsequent interrupt may be 
> ineffectual.
>
> As this uiSafeAcquire(...) API also includes cases where it is more 
> obviously appropriate to throw an InterruptedException, your client will 
> have to handle it, anyway.  Perhaps it can just repeat the attempt in a 
> loop or something?  Probably I need to know more about your particular 
> scenario ...
>
> Cheers,
>
> Christian
>
> Bernd Vogt wrote:
> > Hi!
> >
> > We are useing EMF Transaction in our current project to establish 
> > synchronized model access.
> >
> > The synchronization works fine, but sometimes we get 
> > 'InterruptedException' during a transaction should be started in the 
> > UI thread.
> >
> > The exceptions we get will allways be thrown in the very beginning of 
> > the Lock#acquire(timeout, exclusive) method after checking if the 
> > current thread was interrupted. In our case this method was called 
> > from the Lock#uiSafeAcquire(exclusive) method after the AcquireJob 
> > returns with the status 'UI_REENTERED_STATUS'.
> >
> > I don't understand why the interrupted-check is necessary after the 
> > UI_REENTERED_STATUS?
> >
> > Is there any way to prevent those exceptions?
> >
> > Best regards,
> > Bernd