[Mono-dev] asynchronous exceptions

[Konstantin Triger]

2008/6/18 Bastian Schmitz <bastian.schmitz at udo.edu>:

> Hello Kosta,
> thanks for your reply. I asked myself again what I really need and arrived
> at
> the conclusion that resource leaks are not tolerable. You mentioned that a
> reduction of the program's possibilities could result in safe "hard" abort.
> What do I have to restrict or is this only a theoretical approach?


Consider the following code:
using (Stream s = FileStream.Create()) {
...
}

If you abort the thread just after the file handle is opened, but before
that function returned, the stream will remain opened. In some cases even
Finalizer won't close it. Thus you must restrict anything that may need
explicit disposing. (In general same is true even with lock statement. As
far I know MS CLR explicitly frees all the locks held by the aborted thread,
but I don't know how mono CLR behaves in this case).

Now consider this:

Object x = null;
try {
  x = new Something();
}
finally {
  x.Whatever();
}

If Something ctor never throws, normally, the user code will always run
without exceptions. Now you come and abort it inside Something ctor ->
NullRef Exception is thrown!

So the generalization is that you must restrict usage of try/catch/finally
blocks. This will imply restriction on objects that need explicit disposing,
since without try/catch/finally blocks they cannot be correctly implemented.


>
>
> I suppose i'd like the program to react to certain conditions with an
> exception within a (preferably bounded) short amout of time. Of course this
> assumes that scheduling and garbage collection are somehow playing along.


>
> To use "soft" aborts and control points respectively in a thread, I
> probably
> have to make sure that no code is called that has either no control points
> or
> may take too long to complete. I suppose this also implies not using
> blocking
> functions (apart from those i can interrupt myself).


Agree. I think that if you will be able to inject very intelegenetly the
"control points", you will be able to use "hard" aborts more often. For
example, you may add some special "control points" before and after each
try/catch/finally block, so they will specify entrance/exit to the "unsafe
for hard abort" area by setting some global flag.

Kosta


>
>
> Regards,
> Bastian Schmitz
>
>
> On Wednesday 18 June 2008, you wrote:
> > Hello Bastian,
> >
> > Eventually I would ask what kind of abortion you need "soft" or "hard".
> >
> > Hard abortion means that it will happen regardless of what the thread is
> > doing and can be achieved using Thread.Abort(). It's considered unsafe
> > since it can lead to resource leaks. Note, that "hard" abort is
> inherently
> > unsafe regardless of the platform you use (clr,java,native or whatever)
> > until you restrict the program possibilities.
> >
> >  Soft abortion means that in some "control points" the thread itself
> checks
> > for some condition and if it's not fullfilled "soft" aborts itself by
> > throwing an exception (for example). This kind of abortion is safe since
> > the thread controls in which points the condition is checked. In the same
> > time if the thread does not reach the control point, it won't be aborted.
> >
> > You may consider "hard", "soft" abortion or a combination of them (e.g.
> > soft and later hard after some timeout). For "control points" you may
> > consider using aspect oriented techniques.
> >
> > Hope this helps,
> > Kosta
> >
> > 2008/6/18 Bastian Schmitz <bastian.schmitz at udo.edu>:
> > > Hello list.
> > >
> > > Within the scope of my diploma thesis, I am going to create a (or
> extend
> > > an existing) programming language (+compiler) for the control of
> > > automated vehicles. Right now I am evaluating the use of mono as a
> > > runtime platform.
> > >
> > > I am planning to have a language element, which ensures that a given
> > > condition
> > > stays fulfilled during the execution of block of code. If the condition
> > > is violated an exception should be risen. The condition is (probably)
> > > going to be checked/evaluated by another thread, who should inform the
> > > first one in case of violation of the condition.
> > >
> > > This pattern resembles to the asynchronous exception used by the
> > > Thread.Abort() method being triggered by an external thread, catching
> the
> > > ThreadAbortException and canceling the abort afterwards.
> > > I am wondering if there is a safe way to achieve this functionality
> with
> > > the
> > > crl/mono runtime.
> > >
> > > Best regards,
> > > Bastian Schmitz
> > >
> > > _______________________________________________
> > > Mono-devel-list mailing list
> > > Mono-devel-list at lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>


-- 
Regards,
Konstantin Triger
RSS: http://feeds.feedburner.com/ktriger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080618/e92c175d/attachment.html