AppDomains, Threading and UnhandledExceptions
hello all,
i developing application experiment genetic programming. of now, application able compile model of source classes , wire events , methods according configuration stored in model. also, application can mutate , rearrange model in order test alternative options.
the idea compile , run mutations of models in secondary appdomains, 1 each model.
this works beautifull, code gets compiled, model mutated resulting population executed, , none of dynamic assemblies loaded in primary appdomain.
there catch however, 1 have no solution @ moment.
when user decides write piece of code, can introduce code with possible faults. if such piece of code executes on main thread, the exception can handled , processed safely. not problem there.
however when user decides introduce faulty code , execute on new thread (using classes available in system.threading namespace) the exception cannot handled in way.
this means the appdomain.unhandledexception event gets raised in primary appdomain, , the managing application (the experiment) terminates.
if read information regarding appdomains , threading correctly, design of clr.
my conclusion is not possible to compile , run code on fly, without introducing risk of allowing unhandled exceptions.
is there anyone that knows how tackle problem?
many, many in advance,
peter vrenken - mcpd: enterprise applications developer - sigmax mobile solutions
i developing application experiment genetic programming. of now, application able compile model of source classes , wire events , methods according configuration stored in model. also, application can mutate , rearrange model in order test alternative options.
the idea compile , run mutations of models in secondary appdomains, 1 each model.
this works beautifull, code gets compiled, model mutated resulting population executed, , none of dynamic assemblies loaded in primary appdomain.
there catch however, 1 have no solution @ moment.
when user decides write piece of code, can introduce code with possible faults. if such piece of code executes on main thread, the exception can handled , processed safely. not problem there.
however when user decides introduce faulty code , execute on new thread (using classes available in system.threading namespace) the exception cannot handled in way.
this means the appdomain.unhandledexception event gets raised in primary appdomain, , the managing application (the experiment) terminates.
if read information regarding appdomains , threading correctly, design of clr.
my conclusion is not possible to compile , run code on fly, without introducing risk of allowing unhandled exceptions.
is there anyone that knows how tackle problem?
many, many in advance,
peter vrenken - mcpd: enterprise applications developer - sigmax mobile solutions
this understanding such exceptions not recoverable.
this unfortunate, think microsoft being safe. after all, exception might have occured in unmanaged code. appdomains not provide insulation serious problems in unmanaged code such memory access violations. being said, don't totally agree this.
there ways around it:
1. can use <legacyunhandledexceptionpolicy enabled="1"/>, if word "legacy" doesn't bother you.
2. if application hosted, host can use: iclrpolicymanager::setunhandledexceptionpolicy
fyi, here interesting msdn article on unhandled exceptions:
http://msdn.microsoft.com/en-us/magazine/cc793966.aspx
> conclusion is not possible to compile , run code on fly, without introducing risk of allowing unhandled exceptions.
you sandbox permissions not include ability create threads.
this unfortunate, think microsoft being safe. after all, exception might have occured in unmanaged code. appdomains not provide insulation serious problems in unmanaged code such memory access violations. being said, don't totally agree this.
there ways around it:
1. can use <legacyunhandledexceptionpolicy enabled="1"/>, if word "legacy" doesn't bother you.
2. if application hosted, host can use: iclrpolicymanager::setunhandledexceptionpolicy
fyi, here interesting msdn article on unhandled exceptions:
http://msdn.microsoft.com/en-us/magazine/cc793966.aspx
> conclusion is not possible to compile , run code on fly, without introducing risk of allowing unhandled exceptions.
you sandbox permissions not include ability create threads.
.NET Framework > Common Language Runtime Internals and Architecture
Comments
Post a Comment