|
Hi Luc, can you post your code please? Finally block is not executed, here is my code.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication2
{
class Program
{
static void Main(string[] args)
{
try
{
Environment.Exit(-1);
}
finally
{
Console.WriteLine("Hello world");
}
}
}
}
regards,
George
|
|
|
|
|
Hi George,
you already have my code[^].
I am not surprised your code snippet is fooling you, after all you ask it to
perform console I/O where the application is exiting, hence forms, consoles,
and other UI stuff is winding down. The file system however remains alive to
the very end of the app.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Sorry Luc,
Here is your code, the finally blocked is not executed. Could you reproduce? I am confused.
using System;
using System.IO;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication2
{
class Program
{
static void Main(string[] args)
{
try
{
Environment.Exit(-1);
}
finally
{
StreamWriter tw = File.CreateText("finally.txt");
tw.Close();
}
}
}
}
regards,
George
|
|
|
|
|
Hi George,
my example was on Application.Exit() which causes an Application.Run() to return,
I guess asynchronously by sending a Windows message or something; so the thread
has the opportunity to first execute the finally block.
Your test was on Environment.Exit() which, from your observation, seems to cause
an immediate exit. I trust the exact behavior is hidden somewhere in the documentation.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Thanks Luc,
I think for console and Windows Service application, we should never use Application.Exit, right?
regards,
George
|
|
|
|
|
Application.Exit() causes Application.Run() to return, both make sense in windows apps only.
this has been asked and answered many times in the last couple of days, it is not going
to change any time soon ...
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Thanks Luc,
Question answered.
regards,
George
|
|
|
|
|
I never use Application.Exit; I just call the form's Close method.
|
|
|
|
|
Thanks PIEBALDconsult,
I just want to confirm in console and Windows service application, we should not use Application.Exit to terminate the process, right?
regards,
George
|
|
|
|
|
Hello everyone,
Mentioned in the book -- "CLR via C#", page 15, chapter 1 "The CLR's Execution Model",
--------------------
the C# compiler will emit NOP (no-operation) instructions into the code. The NOP instructions are emitted to enable edit-and-continue feature while debugging.
--------------------
What means "edit-and-continue" feature? Why emitting NOP instructions will facilitate this feature?
thanks in advance,
George
|
|
|
|
|
Hi George
Edit and Continue is that you can stop the running program on a break point, change the code in that method and continue the execution, i.e. you can code while debugging.
Why the compiler adds nops, I don't know
Urs
-^-^-^-^-^-^-^-
no risk no funk
|
|
|
|
|
Thanks Urs,
I am also wondering why NOP instructions will facilitate edit-and-continue feature. Let us wait for comments from others.
regards,
George
|
|
|
|
|
Perhaps it replaces the NOP's with any new sets of instructions if you edit your code while debugging.
I don't really know, but it seems quite possible.
My current favourite word is: Bacon!
-SK Genius
|
|
|
|
|
Interesting point, SK!
But the developer when debugging may insert as many instructions as possible. How many NOP instructions of IL will be generated?
regards,
George
|
|
|
|
|
I didn't mean it would replace just the NOP instruction with other instructions. Infact, thats quite difficult since a NOP is 1 byte and most other instructions are more like 3bytes+
I meant instead of the debugger having to start inserting extra instructions after the current one, or before it. It can just replace (and expand) the current instruction (which is just a NOP).
But of course, what if you remove instructions, what happens then?
I think the answer to this is way beyond me
My current favourite word is: Bacon!
-SK Genius
|
|
|
|
|
Thanks SK,
I agree with the basic policy you posted above. But suppose I can copy and paste a large code segment into current function, save it and continue to run. In this case, I do not think compiler will be smart enough to know in advance I will past a lot of code and will reserve a lot of NOP operations. Any comments?
regards,
George
|
|
|
|
|
Pehaps they are just there for somewhere for execution of the program to wait at, safely without fear of the current instruction changing.
If you stopped on something like push 01 and you wanted to change that to push 02 and exection had paused on that instruction, would it be able to change it? Whereas if you where stopped on a NOP then the instruction will never be changed even if everything else around it is.
I think we need some kinda expert on this one.
My current favourite word is: Bacon!
-SK Genius
|
|
|
|
|
Thanks SK!
I think it has nothing to do with NOP. It is how the function of debugger is designed -- does it allowed to change current statement or not (not means only be able to change statement from next statement to execute). Any comments?
regards,
George
|
|
|
|
|
Here is my guess:
If the compiler inserts a few nops at the _begining_ of a method, it can then replace those nops with a call + ret to another method.
thus it can re emit the entire method with all the changes, and just make a redirect from the original method to the altered method. thus not having to worry about adding too many or removing operands in the original body.
eg (pseudo):
original:
public int Foo()
{
nop
Console.Write("hello");
return 1;
}
altered:
public int Foo()
{
return RuntimeModifiedFoo();
Console.Write("hello");
return 1;
}
public int RuntimeModifiedFoo()
{
Console.Write("hello");
Console.WriteLine ("modified method");
return 123;
}
And if you edit even more, it simply replace the first "return RuntimeModifiedFoo();" with a "return RuntimeModifiedFoo#2();"
MS introduced DynamicMethod http://msdn2.microsoft.com/en-us/library/system.reflection.emit.dynamicmethod.aspx[^]
in .NET 2, and that was at the same time as C# got edit and continue..
My 2 cents
modified on Sunday, April 27, 2008 8:47 AM
|
|
|
|
|
Interesting and smart, Roger!
A further question, if we do not inser NOP, what are the additional efforts?
regards,
George
|
|
|
|
|
I think it might be impossible to do it w/o inserting the nop.
Lets say that we have an empty method that we want to modify.
public void Foo()
{
//empty
}
and lets pretend that it looks like this in memory:
1000000 ret //start and end of foo , we can only alter this single byte w/o overwriting the next methiod
1000001 start of next method
There would simply not be any space for us to insert the call to the modified method there, we can only alter 1 byte and if we alter more we start to overwrite some other method.
(But again, I do not know if my guess is how it works, but Id say it would be the easiest approach.)
|
|
|
|
|
Thanks Roger,
Your idea is cool. Let me know if you have found any related documents. I am interested in this topic.
regards,
George
|
|
|
|
|
In the debugger, you can also set breakpoints on lines like "{" "}". Breakpoints can be only set on instructions, so the C# compiler has to emit NOPs for those lines.
I don't know if edit-and-continue needs any additional NOPs.
|
|
|
|
|
Cool, Daniel!
Let us see if other people has experience to share why emitting NOP will facilitate edit-and-continue feature?
regards,
George
|
|
|
|
|
Daniel is correct, I verified this with reflector:
static void Main(string[] args)
{
if(true)
{
Console.Write("hello");
{
{
{
}
}
}
}
}
got emitted as:
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 1
.locals init (
[0] bool CS$4$0000)
L_0000: nop
L_0001: ldc.i4.0
L_0002: stloc.0
L_0003: nop
L_0004: ldstr "hello"
L_0009: call void [mscorlib]System.Console::Write(string)
L_000e: nop
L_000f: nop
L_0010: nop
L_0011: nop
L_0012: nop
L_0013: nop
L_0014: nop
L_0015: nop
L_0016: ret
}
with one nop for each { and }
|
|
|
|