Positive Mental Attitude

다양한 프레임워크와 라이브러리를 사용하는 요즘의 프로그래밍을 하다가 보면 의례 빠지지 않고 나오는 이름이 Context 다.

웹 프로그래밍을 하는 경우에도 보면 심심찮게 등장하는 클래스들 중에 Context 라는 단어가 들어간 경우가 많다.

(Asp.Net의 HttpContext 나, Java의 ServletContext 같은 것들)

닷넷 프로그램을 하다가 보면, 조금 복잡하고 어려운 내용이다 싶으면 어김없이 Context 라는 단어가 등장하곤 하는데, 이 Context 를 도대체 어떻게 해석해야 좋을지 모르겠다.

일단 사전을 찾아보면, Context 는 '문맥, 정황, 전후관계' 이라고 나온다.

쩝... 별로 도움이 안되는거 같다.

이제부터 내 나름대로 Context 가 가지는 의미에 대해서 이야기를 할텐데,

미천한 나의 경험에서 나온 추측이기 때문에 그 의미가 정확히 들어맞지 않을 수도 있고, 틀릴 수도 있다.

아무쪼록 '저 녀석은 저렇게 생각하는 구나' 정도로 이해해 주면 좋겠다.

보통 XxxContext 라고 하는 클래스들을 보면, 일단 데이터의 집합이다. 어떤 정보의 모음이라는 말이다.

일반적으로 정보의 모음이라고 하면 XxxInfo 정도의 이름이 되는데, 이 Info 와 다른 점이라고 하면,

내가 느낀 바로는, Context 는 항상 '경계, 영역, Boundary' 와 연관되어 있다는 사실이다.
즉 '어떤 영역, 경계를 구분하는 데이터의 모음' 이거나 '어떤 영역, 경계를 넘어갈 때 전달해야 하는 데이터 모음' 의 의미가 강하다는 말이다.

예를 들어, System.Security.SecurityContext 라는 클래스에 대한 MSDN의 설명은, '실행시 보안과 관련된 정보의 묶음'이라고 되어 있다.

SecurityContext 는 ExecutionContext 에 포함되어 있다는 내용도 있는데,

System.Threading.ExecutionContext 클래스 또한, 논리 Thread의 실행에 관한 정보를 담고 있다고 되어 있다.

실제 사용되는 경우와 맞추어 보면, 일련의 프로그램 흐름이 Thread 경계를 넘어서 진행될 때, 이전 Thread와 새로 넘어간 Thread의 실행 흐름을 같게 맞추어 주도록 하기 위한 정보라고 해석 할 수 있게 된다.

예를 들어, 어떤 사용자의 요청을 접수 받는 Thread가 있고, 그 요청을 실제로 처리하는 ThreadPool 이 있다고 해보자. 요청을 접수 받은 Thread가 사용자에 맞도록 보안 관련 세팅을 마쳤더라도, 그냥 ThreadPool에 실행을 요청해 버리면, 처리에 대한 보안 설정은 결국 ThreadPool에 있는 Thread의 보안 설정을 따르게 된다.

이런 경우에, 요청을 접수 받은 Thread가 보안 세팅을 한 후에, ExecutionContext.Capture를 통해 이전 실행 흐름에 대한 정보를 수집하고, ThreadPool의 Thread는 실행시에 이 ExecutionContext.Run 을 사용하여 실행하도록 하면, 다른 Thread 경계를 넘어서도, 같은 실행 흐름을 유지 할 수 있게 되는 것이다.

Asp.Net 프로그래밍을 할 때 등장하는 System.Web.HttpContext 같은 경우에는,

어떤 하나의 HTTP Request-Response 에 대한 정보를 담고 있는 클래스가 된다. 즉 동시에 이루어 지는 여러 HTTP Request-Response 들 각각의 분리시켜 주는 정보의 모음 이라는 말이다.

뭐 당연한 이야기 겠지만, Context 는 여러 경계에서 공유되는 정보 이므로, 한 경계에서 수정한 내용은 경계를 넘어서도 볼 수 있다는 사실도 염두해 둘 필요가 있을 듯 하다.

닷넷에서 등장하는 XxxContext 이름의 클래스 들 몇가지를 나열해 보면,

- System.Runtime.Remoting.Contexts.Context

- System.Threading.ExecutionContext

- System.Security.SecurityContext

- System.Runtime.Remoting.Messing.CallContext

- System.Runtime.Remoting.Messing.LogicalCallContext

- System.Threading.SynchronizationContext

     |

     +- System.Windows.Forms.WindowsFormsSynchronizationContext

     |

     +- System.Windows.Threading.DispatcherSynchronizationContext

헉! 무슨 Context 가 이렇게 많은지...

이중에서 SynchronizationContext 와 그 자식 클래스들이 등장하는데, 이 SynchronizationContext 를 위에서 애써 설명한 Context 의 개념으로 해석해 보면, SynchronizationContext는 동기화 경계를 나타내는 정보의 묶음이며, 이 동기화 경계를 넘어 가려면 어떤 식으로든 이 SynchronizationContext를 사용해야 한다고 생각할 수 있다.

이 SynchronizationContext 는 종종 등장하는 클래스 이므로 나중에 기회가 되면 좀 더 살펴보려고 한다.

이제 두서없는 글의 결론을 내려보자.(다시 읽어보니 글이 영 정신이 없다.^^;)

나의 경우에는,

Context 가 들어간 클래스가 나오면 항상 <1.이 Context 가 구분 짓고자 하는 '경계, 영역' 이 뭔가> 를 따져보고, 이 Context 가 <2.'경계, 영역'을 구분하기 위한 용도인지, 아니면 '경계, 영역'을 넘어가기 위한 용도 인지> 살펴본 다음에, 만약 '경계, 영역'을 넘어가기 위한 용도라면 그 <3.'경계, 영역'을 넘어가기 위해 어떤 식으로 Context 를 사용해야 하는지> 살펴보는 방법으로 그 클래스를 이해하려고 한다.

출처 : http://blog.naver.com/jjoommnn/130034619314

void ModifyShortcutTargetName(string shortcutFilename)

{

WshShell shell = new WshShell();

FileInfo LinkFile = new FileInfo(shortcutFilename);

if (LinkFile.Exists)

{

IWshShortcut link = (IWshShortcut)shell.CreateShortcut(LinkFile.FullName);

link.TargetPath = link.TargetPath.Replace("AAA.exe", "BBB.exe");

link.Save();

}

// 아래 코드는 Windows XP 에서 실행되지 않는다

/*if (File.Exists(shortcutFilename) == false)

return;

var pathOnly = Path.GetDirectoryName(shortcutFilename);

var filenameOnly = Path.GetFileName(shortcutFilename);

var shell = new Shell32.Shell();

var folder = shell.NameSpace(pathOnly);

if (folder == null)

return;

var folderItem = folder.ParseName(filenameOnly);

if (folderItem == null)

return;

if (folderItem.IsLink == false)

return;

var link = (Shell32.ShellLinkObject)folderItem.GetLink;

link.Path = link.Path.Replace("AAA.exe", "BBB.exe");

link.Save();*/

}

void RegisterDLL(string filename)

{

var process = new Process();

process.StartInfo.FileName = "regsvr32.exe";

process.StartInfo.Arguments = "/s \"" + filename + "\"";

process.StartInfo.UseShellExecute = false;

process.StartInfo.CreateNoWindow = true;

process.StartInfo.RedirectStandardOutput = true;

if (6 <= Environment.OSVersion.Version.Major)

process.StartInfo.Verb = "runas";

process.Start();

process.WaitForExit();

process.Close();

}

public bool CheckPassword(string password)

{

if (Regex.IsMatch(password, @"[a-zA-Z0-9~`!@#$%^&*()_\-+={}[\]|\\;:'""<>,.?/]") == false)

return false;

return true;

}

주의할 점은 -, ], \ 앞에는 \를 하나 더 붙여주고 "앞에는 "하나를 더 넣어줘야한다

Console.WriteLine("{0:+00;-00}", 10);

출력 : +10

Console.WriteLine("{0:+00;-00}", -10);

출력 : -10

출처 : http://blog.naver.com/PostView.nhn?blogId=eom913&logNo=159761311

.NET 프로그래밍을 하는 데에 있어 한가지 장점을 꼽으라면 전에 비해 상당히 쉬워진 멀티쓰레드 프로그래밍이라고 할 수 있다. 하지만 많은 개발자들이 놓치는 부분이 쓰레드에서 UI를 접근하는 부분이다.

우선 윈도우즈 프로그래밍에서 UI부분이 어떻게 동작하는지 이해할 필요가 있다. 윈도우에서 UI는 메시지 펌프 (Message Pump)라고 불리는 방법에 의해서 화면에 그려진다. 선하나를 화면에 그린다고 가정하면, 윈도우즈는 그 선을 계속해서 반복적으로 그림으로써 사용자에게 마치 선이 하나가 있는 것처럼 보이게 하는 것이다. 그리고 이를 위해 수 많은 메시지, 즉 인스트럭션이 보내진다.

예를 들어 폼의 이벤트를 살펴보면 OnPaint라는 이벤트를 발견할 수 있다. 이 이벤트내에 int I = 0; 이라는 코드를 삽입하고 브레이크 포인트를 걸어 실행을 시켜보면 윈도우는 보이지 않고 이 브레이크 포인트가 계속 해서 걸리는 것을 알 수 있다. 사용자가 모르는 사이 .NET 프레임웍은 윈도우즈에 해당 UI를 화면에 그리도록 명령을 끊임 없이 보내며 이 이벤트를 발생시키는 것이다.

여기서 한가지 중요한 부분이 있다. .NET 프레임웍은 윈도우즈에 메시지를 보내는 과정에서 이벤트를 발생 시킴으로써 개발자에게자신의 코드를 삽입할 기회를 부여한다는 것이다. 이 모든 부분이 UI에 접근하려는 쓰레드와 관련이 있다.

모든 프로그램은 기본적으로 하나의 쓰레드로 시작이 된다. 따라서 폼을 화면에 그리는 메시지와 이벤트들도 그 쓰레드 안에서 구동이 된다. 하지만 사용자가 시작한 쓰레드는 이 쓰레드와는 별개로 실행이 된다. 따라서 이 커스텀 쓰레드에서 UI에 직접 접근을 하면적절한 마샬링 없이 다른 쓰레드를 침범하는 것이다 (Cross Thread). 다시 말해, UI 쓰레드가 열심히 화면에 폼을 그리고 있는데갑자기 다른 쓰레드가 와서 딴 짓을 하고 가는 꼴이 되버리는 것이다.

이를 위해서 UI 컨트롤들은 Invoke, BeginInvoke 메서드와 InvokeRequired 속성을 지원한다. Invoke 메서드는 동기(Synchronous) 메서드이고 BeginInvoke는 비동기 (Asynchronous) 메서드이다. 이 메서드들은 컨트롤들이 생성된 쓰레드의 메시지 펌프에 커스텀 코드를 삽입하여 그 쓰레드에서 컨트롤를 업데이트할 수 있도록 한다. Win32에서 SendMessage나PostMessage를 생각하면 된다. InvokeRequired 속성은 Boolean 값을 반환하며 Invoke 나 InvokeRequired 메서드를 호출해야 하는지를 알려준다.

Invoke 와 BeginInvoke 메서드는 인자로서 delegate 형태를 받는다. 다음은 Invoke 메서드를 호출하는 방법중 하나이다.

this.Invoke(new MethodInvoker(UpdateMe));

…

void UpdateMe()

{

…

}

MethodInvoker는 프레임웍에서 지원하는 delegate 클래스로 인자가 없는 메서드들을 호출 할 수 있도록 정의가 되어있다. 만약인자를 넘겨줄 필요가 있다면 delegate 을 따로 정의하여 사용하면 된다. 다음은 인자를 갖는 메서드를 호출할 때의 예이다.

Delegate void UpdateMeDelegate(string message);

…

this.Invoke(new UpdateMeDelegate(UpdateMe), “This is the message”);

…

toid UpdateMe(string message)

{

…

}

Invoke 메서드는 동기 메서드이기 때문에 바로 실행되어 긴 시간이 걸리는 작업에는 적합하지 않다. 이런 경우는 비동기 메서드인BeginInvoke를 사용하면 된다. BeginInvoke 메서드는 EndInvoke 메서드와 짝으로 구동이 된다. EndInvoke 는 비동기로 실행된작업을 완료하는 역할을 한다.

IAsyncResult ar = this.BeginInvoke(new MethodInvoker(UpdateMe));

…

this.EndInvoke(ar);

BeginInvoke 메서드에서 실행된 작업이 끝나면 EndInvoke 메서드를 호출하여 작업을 완료한다.

출처 : http://kworks.tistory.com/119