image

오늘 오전에 MS 본사 개발자분이 직접 회사로 와서 vs2013 Native 변경사항에 대한 프레젠테이션을 하길래 듣고 옴. 인터넷 찾아보면 잘 정리된 내용이 더 많이 있겠지만 그냥 개인적으로 오전에 들었던 내용 간략히 정리.

WPO : Whole Program Optimization. 예전부터 있던 기능. /CG와 /LTCG 스위치에 해당한다. 빌드하다보면 ‘/CG(?) 옵션으로 컴파일한 파일이 있다. /LTCG 옵션을 이용하면 성능을 향상 시킬 수 있다’라는 메세지를 간혹 볼 때가 있는데, 저거 뭔지 한 번 찾아봐야지 했던 거였는데 오늘 동작 원리에 대한 설명을 들었다.

원리는 간단한데, 기본적으로 소스파일을 obj로 컴파일 할 때는 소스파일 한 개 단위로 진행하니까 다른 파일에 작성한 코드를 참고할 수는 없다. 그러니 그냥 개별 파일단위 최적화밖에 할 수 없는 게 기본적인 동작 방식인 것에 비해서, WPO를 이용하면 다른 파일에 작성한 코드도 최적화 과정에서 함께 lookup할 수 있게 만드는 것이 컨셉. 그래서 /LTCG – Link-time code generation이 여러 obj파일을 이어 붙일 때 코드 생성을 해야 하는 것이지.

설명을 듣기 전엔 빌드 출력창에 메세지 뜨는거 보면서 ‘뭐야 저건 managed code에서 쓰는건가…’하고만 생각했는데, 궁금해 하던 내용의 설명을 들어 좋았음.

PGO : Profile Guided Optimization. 이 또한 예전부터 있던 기능. 한글판 vs엔 프로필 기반 최적화로 번역되어 있다. 2005였나 2008부터 있었던거 같은데.. 툴 바꾸고 메뉴항목에 있길래 이건 뭐지 하고 몇 번 눌러보고 검색해보고 했던 그 것. 이것도 오늘 내부 동작 과정에 대한 설명을 좀 더 자세히 들을 수 있어서 좋았다.

설명을 듣기 전에 막연히 생각할 때는 하드웨어에 종속적인 최적화를 진행하는 것 같아 망설임이 느껴지던 기능이다. compiler에게 feed시킬 프로파일을 만들어내기 위해 최적화 단계에서 프로그램을 직접 실행하는 절차가 있는데, 이 때 실행 환경이 Intel CPU냐 AMD CPU냐에 따라 거기 맞춰서 최적화를 해버리는 거 아냐? 뭐야 이거 무서워 쓰지 않을 거야.. 하고 생각했음. 근데 CPU 벤더와 아무 상관 없다 ㅎ 그냥 로직의 실행 빈도에 대한 프로파일링이 주로 진행될 뿐이다. 이건 나중에 제대로 한 번 사용해봐야겠다.

PPL : 아마 2010부터 들어갔지. 많이 개선하였다는 내용 설명들. PPL이 vs2010과 함께 나왔을 때는 내부적으로 메모리 누수가 있음을 MS가 공식적으로 인정하기도 했었다(야…). 그 말 들은 이후로 PPL은 기능이나 인터페이스는 둘째치고 안정화 부터가 아직 멀었다고 생각하고 담 쌓은 상태. 요즘은 어떨려나.

AMP : CUDA나 OpenCL은 특정 벤더의 GPU 사용여부에 따라 다른 성능을 낼 수 있으나, AMP은 DirectX를 기반으로 삼기 때문에 이런 이슈가 없다는 것. 음 그래.. 그렇겠네. 난 아직 GPU의 파워를 끌어와야 할 만큼의 프로그램을 만들 일이 없어서 아직 감흥이 없음. GPU는 둘째치고 CPU의 멀티 코어만이라도 잘 쓸 수 있음 좋겠다 ㅎ

__vectorcall : vs2013부터 새로운 함수 호출 규약을 사용할 수 있다. C++/CLI에서는 사용 불가하고, 네이티브 x86/x64만 사용 가능. 이 규약을 쓰면 확장 레지스터를 이용하는 코드에 대한 최적화가 이루어지는 듯. 아 근데 확장 레지스터도 별로 열심히 써 본적이 없어..

x64기반의 컴파일러 : 이 건 재미있는 이슈다. vs2012까지는 cl.exe / link.exe 가 x86으로 컴파일 되었는데, 2013부터는 x64로 빌드된다. 예전의 링커가 만들어 내던 ‘Linker : Out of memory’ 오류는 이제 physical ram이 고자가 아닌 한 거의 안나올거다. IDE 프로세스인 devenv.exe도 x64로 빌드하려나? 궁금하네 ㅎ

C++11/14의 지원 : 현재 지원하는 기능의 목록, vs2013이 올해 말까지 CTP를 통해 지원할 목록, 현재 작업중인 목록 등의 소개. 올해 말까지 많은 항목을 구현 예정이다.

개인적으로 delegating constructor를 기다리고 있는데, 이 부분은 현재 작업중이라 버그픽스하고 테스트 중인 상태라고. 연내 릴리즈되는 일정에는 빠져있더라.

그리고 C++도 자체적으로 async / await를 지원하려고 한다는 걸 오늘 알게 됨. 지금은 C++11이나 C++14에선 채택되지 않았으나 C++1y 단계 스펙으로 검토되고 있고, vc 2013에선 CTP를 통해 올 연말 내에 비표준 키워드 __async/__await을 지원할 예정. feature 이름은 resumable functions.

C++ REST SDK : 트위터를 통해 존재는 알고 있었지만 딱히 관심은 없었던 라이브러리. 오늘 간단한 http client 샘플코드를 봤는데, async response를 받아 처리하는 방식의 인터페이스에 급 호감을 느꼈다. 분석해보고 싶어졌어!

개인적으론 c++에서 lua의 table이라든지, json, xml같은 typeless한 데이터를 다루는 것은 포기하는게 정신 건강에 좋다는 생각을 가지고 있다. 차라리 루아나 C#을 쓰는게 훨씬 낫지. REST의 SDK는 json을 어떻게 다루고 있을까. 아마 C++의 강력한 타입 제한 때문에 분명한 한계를 가질 것이다. 그래서 그리 큰 관심은 안감. 암만 좋아져도 C#보다 못할거야. http 통신할거면 차라리 다른 언어를 쓰라구.

하지만 한 번 다운받아서 둘러보기나 해야겠다는 생각을 했다.

 

IDE 변경사항

enhanced scroll bar : 링크한 페이지엔 한눈에 딱 들어오는 스샷이 없네. 딱 sublime 생각하면 된다. 미니맵 방식의 스크롤을 사용할 수 있고, 스크롤에서 브레이크 포인트 위치 같은 것도 보여진다.

편리해 보이긴 하는데, 소스코드가 미친듯이 길면 어떨까? 우리회사 모 프로젝트에는 소스파일 하나가 2메가 단위인 것도 있단 말이다. (…;;)

quick-launch : 우측 상단에 있는 검색창. 이건 지금 vs2012에도 있고.. 지금도 기능 비슷하게 돌아가는 듯 한데.. 더 강화됐다고는 하네. C++ 프로젝트 설정에 있는 항목들이 검색 가능해진 것은 좋아 보인다. 지금 해보니 vs2012에서는 안됨.

Navigate-to : view가 시원(?)해졌다. 지금은 큼지막한 팝업창이 떠서 candidates가 노출되는 list control을 봐야 했는데 이젠 Incremental search처럼 작은 edit control 하나만 뜬다. 동작도 incremental search같이 매번 타이핑마다 소스코드창이 실시간으로 바뀌어 보임.

이거 참 빌드하는 중에도 사용 할 수 있게 안되냐고 물어봤어야 하는데. 깜박했다.

Peek-definition : 단축키 Alt + F12. 말로 설명하기 애매하다. F12키의 goto-definition보다 좀 더 임시적인 공간에 코드를 보여준다. 링크 참조.

code formatting configuration : 코드 포맷팅 자동 조정 능력의 향상. 자동 조정되는 포맷팅 방식을 설정창에서 변경할 수 있다.

brace complition : (), {}등 괄호를 입력할 때 동작을 개선. 긴 말 필요 없고 sublime과 똑같아진 듯. 개발팀이 sublime의 영향을 많이 받은 거 같다. 여는 괄호를 타이핑하면 닫은 괄호가 함께 생기고, 다시 닫는 괄호를 타이핑해도 적절히 over-writing처리한다.

header / code switching : 드디어 들어간 영광의 기능. 네이티브 개발자가 개발 시간 중에 가장 많이 사용하는 기능. 가장 간단하면서 가장 요긴한 바로 그 기능 ㅡㅜ. 헤더와 소스파일간 이동기능이 드디어 기본으로 들어갔다. visual assist에겐 큰 타격이 아닐 수 없다. 보고 있나 홀 토마토?

 

대충 정리는 요정도만. 정적 분석 (/analyze)의 강화, 윈도우 8.1 지원사항 등은 관심사항이 아님. QnA 시간에 _VARIADIC_NUM와 빌드 속도에 대한 질문을 했는데, variadic template이 지원되면 해결될 사항이니.. 그 외엔 대단한 답변을 들은 것은 아니지만, 혹시나 2013에서도 빌드속도에 대한 불만족이나 기타 의견이 있다면 피드백을 달라며 발표자분이 직접 명함을 주었다. 영작하기 싫으니 그냥 빌드속도 빨라졌음 좋겠다…;;

그리고.. Inter-op debugging의 지원으로 C++을 사용하면서 C#, Python같은 언어들도 같이 디버깅 할 수 있게 되었는데, Lua는 지원되지 않는다고 함. 미지원 되는 언어를 사용자가 임의로 디버깅 되도록 설정할 수 있는 방법도 현재는 없음. 그런거 할 계획도 없음. 개발자가 그런 기능을 필요로 하는지도 몰랐음. (몇 차례 발표했지만 이런 질문을 처음 들었다고.) 디버거 개발팀에 건의해 보겠음.

그리고 IDE의 로딩 속도가 많이 빨라졌다. 체감되는 무게감은 2012보다 더 가볍게 느껴질듯.

Posted by leafbird 트랙백 0 : 댓글 1

댓글을 달아 주세요

  1. addr | edit/del | reply Favicon of https://devnote.tistory.com BlogIcon leafbird 2013.09.27 22:36 신고

    C++11/14 STL Features, Fixes, And Breaking Changes In VS 2013
    http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx
    변경사항 꽤나 많구나. 2013갈아타면 여러가지 좋아지겠군.

바쁜 현대인을 위한 세 줄 요약

  1. 이 책 아주 멋지구나 –_-)b
  2. 꽤나 오래된 책임. 초판이 2003년 7월. 십 년 된 책…
  3. 난 이걸 왜 이제야 보고 있는거지 ㅜㅠ…

여기까지. 아마 SNS에 썼으면 이렇게 쓰고 말았을 텐데, 오늘은 간만에 블로그에 글이나 한 번 적어보고 싶어져서 좀 더 길게 적어볼까 한다. 자기 전에 머리 말리고 자려면 시간도 좀 남고 해서…

 

1. 이 책 아주 멋지구나 –_-)b

이 책을 손에 넣게 된 게 올 해 5월 쯤이다. 책을 구하면 아주 열심으로 읽어야겠다고 생각한 것에 비하면 매우 느린 속도다. 책 구했을 땐 한참 자바스크립트에 재미 들려서 node.js 가지고 노느라 시간 많이 보냈지. 책 목차가 총 10장인데 지금 7장 읽는 중. 내용이 난이도가 좀 있어서 한 번 읽고 모두 이해하고 있는 상태는 아니지만 아주 못 읽을 정도는 아니다. 수학 강의 들을 때랑 약간 비슷한 느낌인데, 교수님이 칠판 가득히 증명하는 수식을 솔직히 한 두 부분 정도는 이해가 잘 안 가지만 어쨌거나 그래서 마지막 정리된 공식은 y = f(x)이니 문제 풀 때 사용하면 된다 쯤은 머리에 남는 것과 비슷하다. 라이브러리 내부 구현과 설명이 좀 이해 안된 부분이 있기도 한데 어쨌거나 그래서 인터페이스 사용법이랑 대충 동작 원리 정도는 이해가 됨 ㅎ

내용도 번역도 모두 만족스럽다. C++를 다루는데 아직 이 책을 읽지 않은 사람이 있다면 읽어보기를 초강추한다. (아마 구하기 힘들겠지만)

 

2. 꽤나 오래된 책. 십년 된 책…

 

Old.

책에 소개된 기법이나 코드 중에는 익숙한 내용도 다수 있다. type2int 같은 건 예전에 이 블로그에도 한 번 적었던 적도 있는데 지금 std 라이브러리에 들어가 있고, traits도 뭐 대충 뭔지는 많이들 알고 있지. 거기에 Functor 클래스나 Bind도, Smart Pointer도 Loki의 구현을 사용하기 보다는 std에 정식으로 들어간 <functional>의 구현을 선택하는 게 더 나을 것 같다. 그리고 Functor 클래스가 제공하는 기능의 상당 부분은 이제 C++11의 lambda가 언어 자체적으로 지원하게 되면서 구현을 생략하거나 많이 간소화 할 수 있겠다는 생각이 든다. (Loki는 왜 버전업을 안 할까 하는 생각도 들었음)

하지만 그럼에도 이 책의 장점은 분명히 있다. 친절하고 상세한 설명은 Loki 코드와 구현의 의도를 멋지게 연결 지어준다. 그냥 잘 정리해둔 라이브러리 가져다 쓰기만 하면 장땡인 사람은 차라리 MSDN을 읽어라. 템플릿은 담쌓아놓고 살겠다는 사람이 아니라면 이 책의 설명을 보면서 분명 템플릿 코드를 다루는 다양한 방법들에 반드시 매력을 느낄 것이다. 저자의 내공앞에 한없이 작아지는 자신을 만날 수 있다...

절판.

그렇다. 이 책은 절판되었다. 그래서 구하기 힘들다. 약간 핑계 같지만 내가 책을 이제야 읽게 된 것도 구하기가 힘들었던 때문이기도 하다. 책을 읽고 싶은데 구할 길이 없어서 ‘왜 출판사는 이런 책을 재발행을 안하나’하고 생각도 했다. 구하고 나서 좀 읽다 보니, 출판사 입장에서는 개정판이라면 모를까 10년 전 책을 그냥 재발간 하는 게 좀 애매할 것 같기도 함. 요즘 같은 Native Programming 비수기(?)에 수요가 얼마나 있을까 싶기도 하고.

이런 책들을 PDF나 이북으로 팔면 출판사도 독자도 서로 좋을 것 같은데, 출판사는 그런 생각 안 하나 모르겠다. 이 책은 주위에 권하고 싶어도 구하기가 힘드니 권할 수도 없다. 어쩔 수 없다 구하기 힘든 사람은 원서를 읽어라…;;

 

3. 난 이걸 왜 이제야 보는건가 ㅠ

진정 개탄스러운 것은 이 대목이다. 이런 주옥같은 내용을 이제야 읽고 있다니 ㅠ 심지어는 며칠 전 팀장님한테 구두로 설명 받은 여러 가지 내용들이 이 책을 읽어가다 보니 하나 둘 다 튀어나오고 있고, 근데 그 책이 이미 십 년 전부터 존재하고 있던 책이란 거지 ㅠㅠ... 심지어 원서는 더 오래 됐겠지! ㅡㅜ

Loki 라이브러리는 멋진 구현들을 가지고 있지만 사실 많이 쓰이고 있지는 않은데, smart ptr이나 traits 같은 거 대부분은 boost에 있다고 치고, typelist는 없지 않나? 왜 안 쓰지? 하고 생각했으나 좀만 검색해보면 이름이 달라서 그렇지 이미 존재(boost.MPL Sequence). 링크 걸어놓은 곳의 답변처럼 Loki는 Modern C++ Design 책과 함께 기능 구현을 이해하기 위한 학습용으로 좀 더 가치가 있는 듯 하다.

코흘리개 초짜시절 David Abrahams의 C++ TMP 책을 읽다가 밥상머리를 뒤집고 포기해버린 적이 있는데, Modern C++을 먼저 읽고 C++ TMP를 읽는 게 순서인 것 같다. 그 땐 Modern... 을 먼저 읽었더라도 지금보다 더 이해하기 힘들어 똑같이 밥상을 엎었을지도 모르겠으나, 아무튼 좀 더 일찍 읽지 못한 게 아쉽다.

C++은 어느 정도는 알고 있다고 생각했는데 아직도 공부할 내용은 너무 많다. 윈도우도 한 때 어느 정도는 알고 있다고 착각한 적도 있지만 아직도 모르는 부분이 너무 많다. 작년부터는 애기가 생기고 한동안 육아 가사에 시간을 많이 쏟았는데 이젠 다시 슬슬 개인 공부시간을 좀 챙겨야겠다.

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

IMG_0060

정말 오랜만에 재미있게 읽은 책이자,

정말 오랜만에 처음부터 마지막까지 완독한 책이며,

최초로 완독한 이북이면서,

최초의 아이북스 구매 컨텐츠이다.

 

영화 각본가와 게임 개발자 사이에서 고뇌하는 20대 초반의 불안한 영혼에서부터, 페르시아 왕자 1편을 대박내고 ‘돈이 필요 이상으로 너무 많은’ 상황이 되기까지의 조던 메크너를 성장영화 감상하듯이 볼 수 있다. 게임을 좋아하는 이라면 누구나 재미있게 읽을 수 있을 것이다.

책을 읽으면서 여러 가지 생각이 들었는데, 가장 놀랐던 것은 조던 메크너의 꼼꼼함이다. 일상을 이렇게 꼼꼼하게 기록해 두다니. 책으로 엮인 것은 8년치 분량의 일기이지만 그 이후로도 일기는 계속 이어진다. 단지 페르시아 왕자와 관련된 부분만 발췌됐을 뿐이다. 게임을 보아도 만든이가 꽤나 꼼꼼한 사람일 거라는 짐작은 할 수 있지만 이 책의 착실한 (좀 과하다 싶기까지 한) 기록을 보고 정말 놀랐다.

내 인생에 대한 쓸데없는 통계치를 모으는 노력의 일환으로 계산해본 바, 지난 4년간 내가 ‘페르시아 왕자’ 개발에 대략 3,800시간, 그러니까 풀타임 작업 일수로 쳐도 2년을 채울 만큼의 시간을 쏟았다는 걸 알았다.
 - 1990년 6월 20일 내용 中.

프리랜서 프로그래머 중에 저런 거 계산하는 사람이 있나? 진짜 꼼꼼하다. 게임 서버 짜도 아주 잘 짜실듯 ㅎ

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

image

영문판이 돌아다닐 때는 그냥 그런 가보다 하고 있다가, 얼마 전에 트윗 타임라인에 한글판 링크가 보이길래 다운받아 읽어봤다. 밸브의 업무 분위기란, 저런 곳에서 일한다는 것은 어떤 걸까 호기심을 갖게 만든다.

입사자용 가이드를 이렇게 깔끔히 잘 정리하다니. 그리고 그것을 공개해 외부의 개발자들에게 회사 홍보 및 호감도 상승 자료로 이렇게나 잘 써먹다니. 대단한 아이디어다.

새로운 사람을 채용하는 일이 우주에서 제일 중요하며, 숨쉬는 것보다 중요하다는 강조문구를 보니 괜히 도전욕구가 샘솟기도 했지만… 난 영어가 안되잖아… 아마 난 안될 거야 ㅜㅠ… 얼마 전에 흥배형님이 한살이라도 어릴 때 영어 공부하라고 했던 충고가 떠오른다.

그 누구도 실수나 실패를 해서 밸브에서 해고된 적은 없다. 그런 식으로 운영되는 건 우리 방식에 맞지 않는다. 실패의 자유가 있는 환경은 회사의 매우 중요한 부분이다. (20p)

우리는 강의를 한다던지 멘토링과 같은 공식적인 ’교육’을 하지 않는다. 그 이유는 시니어라 불리는 사람들에게는 이 것이 매우 비효과적 이기 때문이다. 우리는 퍼포먼스가 뛰어난 사람들은 스스로 성장한다고 믿는다. (38p)

채용을 잘하는 것은 우주에서 제일 중요한 일이다. 어떤 것도 이만큼 중요한 건 없다. 숨쉬는 것 보다 중요하다. (44p)

전사적으로 볼 때 우리는 협업을 잘하는 사람들에게 높은 가치를 부여한다. (45p)

우리는 우리보다 나은 사람을 채용해야지 더 못한 사람을 채용하면 안 된다. 할 일이 너무 많아 보일 때는 조금 못한 사람을 채용하는 것이 자연스러운 방법처럼 보인다. 단기적으로 보면 아무도 채용하지 않는 것보다 일이라도 할 수 있는 사람을 채용하는 것이 더 나은 선택으로 느껴진다. 하지만 이 것은 매우 큰 잘못이다. (47p)

완전 무결성을 추구할듯한 저 채용 과정에서도 아마 미처 걸러내지 못한 이상한 신규입사자가 반드시 존재할 것이다. 종빈이형의 ‘병신 존재 이론’에서 이미 이론화 되었다. 가이드북에도 잘못 채용했다고 판단이 드는 사원은 발견 즉시 퇴사시킨다는 내용이 있음(45p) ㅎ

Posted by leafbird 트랙백 0 : 댓글 3

댓글을 달아 주세요

  1. addr | edit/del | reply Favicon of http://blog.outsider.ne.kr BlogIcon Outsider 2013.05.17 02:58

    검색해도 안나오는데 번역본이 있나요?

이 책은… 본격 기술서적은 아니지만 일상 블로그에 올리긴 뭣해서… 여기에 포스팅.

최근에 중고 맥북(흰둥이, 2010 Mid, MC516)을 영입, 저녁에 꼬맹이 목욕 시키고 재우고 나면 조금씩 OS X를 만져보고 있다. 아직 개발환경을 적극적으로 살펴보는 단계까지는 아니고 그냥 일반 유저 입장에서 이것 저것 보는 중. 애플에 우호적인 개인 성향 때문인지는 몰라도 현재까지는 아주 만족스럽게 사용하고 있다.

일반 엔터테인 용도로 볼 때는 이전에 가지고 있는 아이폰, 아이패드들과 연동이 좋다는 점이 우선 아주 좋고, iPhoto 같은 프로그램도 제법 마음에 든다. 윈도우의 피카사보다 나은가 하고 물으면 또 다른 이야기지만.. 단순하고 직관적으로 사용하기엔 무난한 듯.

낯설기도 하지만 새로운 환경이 신선하고 재미있다. 손에 익은 윈도우에 비해 답답한 것도 있지만 하나씩 알아가는 재미가 더 크다. 제스처를 사용하는 트랙패드는 윈도우보다 훨씬 편하고 만족스러워서, 나는 주로 키보드를 많이 쓰는 편인데도 맥에서는 키보드에 손 올릴 일이 거의 없다. 매직 마우스는 안 써봤지만 아마 트랙패드보다 불편할 것 같다.

OS는 대체적으로 ‘Just It Works’라는 모토에 맞게 직관적으로 사용할 수 있다. 간간히 생각한 대로 동작하지 않는 경우에는 이 책을 좀 찾아봤다. 처음엔 .dmg, .pkg 파일 개념도 없어서 인터넷에서 파일 다운로드 할 때도 끙끙댔는데, 그럴 때 도움을 많이 받았다. dock에서 부채꼴 모양으로 막 늘어나는 것도 처음에 보면 당황스럽고, 파인더 처음 열었을 때 ‘나의 모든 파일’의 해괴한 동작도 초보 사용자를 주눅들게 하는데(도대체 HDD에 파일구조가 어떻게 돼있는 건지 @.@…), 그런 것에 헤매고 있는 분들이라면 가볍게 이 책을 읽어볼 것을 추천.

 

덧. 맥을 처음 쓴다 해도 꼭 책이 필요한 수준은 아님. 구글에 검색하면 대부분 해결 가능. 책에서는 좀 더 깊이 있는 수준을 기대했지만 – bash 설정이라든지 하는 – 그런 건 다른 책을 찾아봐야 할 듯 하다.

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

우연히도 바로 얼마 전에 읽었던 ‘손에 잡히는 정규 표현식’에 이어 이번에는 손에 잡히는 vim을 읽게 되었다. 둘 다 인사이트에서 출간된 책이어서 ‘손에 잡히는 …’ 시리즈가 여러 권인가 하고 찾아보니 그렇지도 않다. 딱 이 두 권만 제목이 이런 것 같은데, 우연찮게 이걸 시리즈로 읽어버림.

일단 책이 좋다. 마음에 든다. 정규 표현식 책도 빌려서 읽고 바로 사버렸는데, vim 책도 빌려서 다 읽고 나니 사고 싶어진다. 정말 종이책은 이제 안 사야지 했는데.. 인사이트가 책을 잘 만드는구나 ㅜㅠ.. 자꾸 내 지갑에서 돈을 강탈해 가고 있엉..

정규표현식도 그렇고, vim도 그렇고.. 하나는 개념(정의?)이고 하나는 에디터 s/w이지만, 프로그래머의 입장에서는 둘 다 생산성을 높여줄 유용한 도구(tool)들이다. 가까이 두고 손에 익을 수록 효용 가치가 늘어나는 것들인지라, 이런 책들은 소설책 읽듯 한 번 읽고 지나치기가 참 애매하다. vim은 자주 사용하는 명령어들만 어디 따로 정리해둬도 굳이 책까지는 필요 없을 것 같긴 한데.. 그렇게 따로 시간 들이고 정성 들여서 정리를 해놓을 것 같지가 않아서 말이지. 그럼 또 하루 이틀 미루다 그냥 손에서 멀어지고 말겠지.

vim은 예전에 대학교 다닐 때 엄청 사용했었다. 당시에 학과에서 제공해주는 유닉스 계정과 10mb짜리 공간에서 홈페이지 만드는 것에 아주 재미가 들려 있었는데, 이 때 터미널 접속으로는 vim만 사용할 수 있었기 때문. 보통 계정의 용도는 과제 제출이나 실습 때만 접속해서 코드작성 하고 빌드 & 제출하면 그만이었는데, 나는 시스템 관리하는 선배한테 쫄라서 계정 공간을 50Mb인가로 늘려 받고는 열심히 vim만 가지고 html 마크업을 짜고는 했다. 그때에도 vim을 많이 썼다 뿐이지, 기능을 다양하게 잘 썼다고는 할 수 없었지만… 그것마저도 요즘은 많이 잊어먹어서 정말 간단한 기능만 사용하고 있다. 이번에 책을 읽으면서 잊고 있던 기능들을 다시 보니 예전 학교 다닐 때 생각이 많이 났다. (그게 벌써 십 년 전 얘기라니 ㅠㅠ)

지금도 윈도우에서 gVim을 사용하고는 있는데, 이제는 거의 viewer 수준으로만 쓰고 있다. 이참에 vim을 좀 더 공격적으로 전진배치해서, vs에서도 사용하고 크롬에서도 사용해볼까 하는 생각도 있음. 그리고는 궁극적으로는 해피해킹 스타일의 미니사이즈 키보드로 갈아타버리는 거지. 눈독들이고 있던 키보드가 품절인 것 같긴 하지만… 지르려고만 하면 예쁜 물건은 많다. 돈이 문제지.

vim의 기능들 중에 전에는 알고 있었는데 까먹었던 기능들을 다시 보고 싶어서 읽었는데, 예전에도 몰랐던 기능들도 많이 알게 되었다. vim 7.x부터 지원되는 탭으로 열기 기능은 예전엔 몰랐던 기능(예전엔 존재도 안했던 기능이지만..). vim의 도움말은 자체적으로 :help를 쳐도 볼 수 있고, 킨들에서 무료 이북도 볼 수 있건만 아무래도 접근성 측면에서 국내 저자분이 직접 적은 한글로 된 책이 영 편하다. 요즘은 윈도우 외에 리눅스나 OS X도 배워보고 싶은 마음이 있는데, 그걸 생각하더라도 vim을 좀 더 익숙하게 만들어두면 편할 것 같다.

Posted by leafbird 트랙백 0 : 댓글 2

댓글을 달아 주세요

  1. addr | edit/del | reply Favicon of https://devnote.tistory.com BlogIcon leafbird 2012.12.10 15:48 신고

    vimium 이건 너무 좋네요! 꼭 사용해 보시길 강추합니다. f키가 정말 환상적이고, 웹서핑 하는데 마우스가 전혀 필요없어지네요 :)

    http://blog.lawfully.kr/2012/11/gugeul-keurom-igseutensyeon-vimium-sogae.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+lawfullykrblog+(lawfully+blog)

  2. addr | edit/del | reply Favicon of https://devnote.tistory.com BlogIcon leafbird 2012.12.10 15:49 신고

    그리고... viemul 이 물건은 일단 유료라... 잠시 고민중. 트라이얼만 우선 한 번 써볼까 싶음.

정규표현식(regular expression)을 가끔씩 쓸 일이 있는데, 한동안 잊고 살다가 오랜만에 한 번 써볼까 싶으면 늘 문법이 가물가물하다. +, *, ?, .(comma)같은 기초적인 문법들만 겨우 생각날 뿐이지만, 정규 표현식을 사용하려고 맘먹었다는 것은 추출하고자 하는 문자열이 어느 정도 복잡성이 있다는 말이고, 그러기엔 머리가 기억하고 있는 문법들은 너무 빈약하기 일쑤다.

이번에도 늘 그렇듯 정규 표현식을 구글링 하다가, 이거 나중에 한참 지나면 또 까먹을거 같고.. 그러면 또 검색할거고.. 그다가 잠깐 써먹고 또 까먹을거고.. 계속 반복일 것 같아서 작전을 변경. 도서관에 가서 책을 빌렸다.

이 책이다. 처음엔 그냥 대수롭지 않게 ‘인터넷 검색 대신 책에서 찾아보자’.. 하는 기분으로 읽었는데, 정리가 너무 잘되 있어서 깜짝 놀랐다. 모든 문법에 대해서 happy case와 bad case의 풍부한 예제가 들어있고, 그럼에도 불구하고 책이 얇고 군더더기가 없다. 책의 원 제목이 ‘Regular Expressions in 10 Minutes’인데, 과연 컨셉에 맞게끔 단시간에 정규 표현식을 습득할 수 있게 되어있다. 레퍼런스용으로도 처음 학습 용으로도 아주 훌륭하다.

이젠 C++에도 표준 라이브러리로 지원하는 시대가 왔고, 이미 regex를 빈번히 사용하는 웹쪽 기술은 나날이 영역이 넓어져 가고 있으니 이 책은 곁에 두고 보는 게 좋을 것 같아 책을 구매해 버렸다. 이제 종이책은 어지간하면 안 사야지 했는데, 이 책은 책꽂이에 꽂아두고 바로 바로 꺼내보는 게 좋을 듯. 확실히 정규 표현식의 접근성을 높여준다.

책 뒤에 부록을 보면 여러가지 엔진별로 regex tester 툴을 제공하고 있다. 원서 안내 페이지(?)에 가면 받을 수 있고, .NET 버전도 존재한다. 헌데 ASP / ASP.NET 버전으로 짜여져 있어서.. 돌릴려면 아마도 iis가 필요… C# 버전을 내가 직접 만들까 했는데 이미 vs extension에 쓸만한 플러그인이 있음 ㅎ vs2010과 vs2012 모두 지원한다.

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

  재미있는 책이다. 책의 내용이 재미있다는 말도 되지만 일단 프로그래머의 이야기를 다룬 소설이라니. 이런 장르를 과연 누가 쉽게 쓸 수 있단 말인가. 임백준씨의 책은 이전에도 즐겨 읽었지만 이 책은 소설이라는 장르의 차이가 있어 또다른 재미가 있었다. 소설은 소설인데 글 속에서 Perforce와 eclipse가 아무렇지 않게 튀어나오니 반갑고 신기했다.

책 속의 내용들은 픽션인지라, 실제의 분위기는 또 어떨지 모르겠지만, ‘뉴욕이든 한국이든 프로그래머들 모여 앉은 집단의 분위기는 비슷하구나’ 하는 생각을 했다. 북미의 프로그래머들은 뭔가 엄청 다르지 않을까 생각했는데.. 어차피 거기도 버그 내고 디버깅 하고 릴리즈 하고 사고 터지고 수습하고… 다시 코딩하고 버그 내고 디버깅 하고 … 똑같아. 그리고 종빈이 형의 ‘병신 존재 이론’의 영향 때문에도 뭔가 해외 엘리트 프로그래밍 집단에 대한 환상 같은 게 많이 사라진 상태다.

.. 이것은 프로그래머라면 누구나 겪는 딜레마이다. 프로그래머는 현재를 살아가고 버그는 과거에 속한다. 그들은 결코 한 날 한 장소에서 만날 수 없다. <시월애>에 등장하는 전지현과 이정재처럼 프로그래머와 버그 사이에는 언제나 시간의 간극이 존재한다.  - page 94.

아 참 글을 잘 쓴다. 아마도 임백준씨는 기술서적 말고도 문학류의 독서도 많이 할 것 같다. ‘프로그래머는 현재를 살아가고 버그는 과거에 속한다’는 표현 좀 봐라. 이영도 작가의 판타지 작품에 나올법한 표현이 아닌가. 나도 글쓰기나 표현력을 포함해 이것 저것 다양한 분야의 자기계발을 해야 하지 않을까 하는 생각을 했다.

이 책은 소설이지만 중간 중간 임백준씨의 이전 에세이나 컬럼들 같은 내용도 많이 들어있다. 그게 저자의 목소리가 아니라 작품 속 캐릭터의 목소리로 적혀있는 것이 이 책의 차이점이다. 그래서 그런지 어떤 주장들은 좀 더 힘있고 강력한 어조로 적어놓은 부분도 있다. 실력 없이 경력만 화려하거나 입담만 강한 허세 프로그래머를 디스하는 글귀들은 완전 돌직구를 던지고 있다. 이런 부분을 읽으면서는… 예전에 함께 일하며 힘든 세월을 보내게 했던 여느 리더들과 팀원들의 얼굴이 몇 명 지나가기도 하더군(쓴웃음). 내 대신 이렇게 속 시원하게 디스를 해주니 후련한 기분이 들었다.

진정한 실력이 없이 흉내만 내는 사람은 숨을 곳이 없다. 이력서 상의 직장 경력이 아무리 풍부한들, 나이가 많은들, 일류 대학을 나왔다고 한들, 튼튼한 연줄을 붙잡고 있다고 한들, 서류상의 화려함은 그가 작성한 코드의 구조와 성능 앞에서 거짓을 말할 수 없다. 프로그래밍에서는 무엇보다도 옆에서 함께 일하는 동료들의 눈을 속일 도리가 없다. 그래서 프로그래머들은 자신의 리더를 오직 실력만으로 결정한다. – page 69

입으로는 최근에 유행하는 신기술을 언급하고 온갖 고상한 이야기를 늘어놓아도, 자기가 실제로 만든 소프트웨어로 실력을 인증하지 않으면 프로그래머로서 설 땅은 없다.  - page 241

요즘은 실력 뛰어난 프로그래머들과 함께 일해서 행복하다. 나도 내 팀원들이 행복하게 일할 수 있게 해주는 좋은 프로그래머가 돼야지.

Posted by leafbird 트랙백 0 : 댓글 4

댓글을 달아 주세요

  1. addr | edit/del | reply Favicon of https://catch-22.tistory.com BlogIcon -22 2012.11.03 07:48 신고

    얘기는 여러번 들어봤는데ㅎㅎ
    리뷰 읽으니 더 기대가 되는데요?ㅎㅎ

  2. addr | edit/del | reply 견습생 2012.11.27 22:38

    히야~ 아래의 두 문장이 정말 와닿습니다.

원래는 스터디 진도에 따라 정리하려고 했는데 많이 늦어지고 있다 ㅜㅠ…

 

6. 스레드의 기본

4장 프로세스와 마찬가지로 스레드의 기본적인 설명들이 자세히 들어있다.

스레드의 생성 : 새로운 스레드를 생성할 수 있는 함수는 윈도우가 제공하는 CreateThread, CRT가 제공하는 _beginthread와 _beginthreadex 이렇게 세가지의 선택이 있다. CreateThread를 바로 호출하면 CRT에서 사용하는 코드의 초기화 처리가 되지 않기 때문에 _beginthreadex를 써야 한다(226p). 그리고 이전 버전의 함수인 _beginthread는 절대 사용하지 말라고 되어 있는데, 이유는

  1. 보안 특성 설정 불가,
  2. suspend상태로 생성 불가능,
  3. 스레드ID획득 불가,
  4. _endthread는 종료코드를 항상 0만 반환,
  5. _endthread가 자체적으로 스레드 핸들을 닫기 때문에 스레드 커널 오브젝트에 접근 불가능 상황 발생

…정도가 있다(236p). 앞에 세 가지 이유는 절대 쓰지 말아야 할 정도까지는 아닌데, 뒤에 두 가지 이유는 치명적일 수 있다. 몰랐던 사실 +_+)

스레드의 종료 : 종료에 관련된 함수가 2개 존재. ExitThread와 TerminateThread인데, ExitThread는 함수를 호출한 스레드 자신을 종료하는 것이고, TerminateThread는 다른 스레드를 종료할 수 있는 함수다. 둘 다 사용하는 것은 좋지 않다. 매우 다양한 이유가 있다. 상식적으로 생각해도 진행중이던 스레드를 갑자기 닫아 버리는 처리는 좋아보이지 않지만, ExitThread로 종료된 스레드는 C/C++ 리소스가 정리되지 않고(218p), TerminateThread로 종료된 스레드는 스레드 스택도 정리되지 않는다(219p). 스레드 함수가 자연적으로 반환되도록 종료시키는 것이 가장 좋다. 만약 스레드 함수가 안정적으로 반환되었더라도 CreateThread에서 받은 핸들을 닫아주지 않았다면 스레드 커널 오브젝트는 파괴되지 않고 남아있다(220p).

Section 6 스레드의 내부, Section 7 CRT 라이브러리의 고찰 부분에서는 스레드의 바닥 부분에 대한 설명이 나와있다. 쉽게 말해,

스레드 콜스택의 가장 아래 RtlUserThreadStart 함수부터, _beginthreadex 함수 내부의 코드들까지.. 스레드의 시작과 종료에 대한 내부 처리들을 설명해준다. 여태껏 윈도우 프로그램 짜면서 한 번도 궁금해 본 적도 없고 들여다 본 적도 없는 부분이었는데 설명을 읽으며 아주 재미있었다.

허위핸들 pseudohandle

핸들 중에는 실제 유효한 값을 갖는 핸들 말고 허위 핸들이라는 개념이 있다. 이런 핸들의 경우 다른 스레드나 프로세스로 전달해 공유할 때 문제가 생길 수 있는데, GetCurrentProcess(), GetCurrentThread() 함수로 얻는 핸들은 허위핸들이다. 고유한 커널 오브젝트를 가리키는 것이 아니어서, 허위 스레드핸들을 다른 스레드로 넘길 경우, 이 핸들을 자신을 사용하여 함수를 호출하는 스레드를 가리키게 된다. 허위 핸들을 실제 핸들로 변환하고자 하는 경우에는 3장에서 소개됐던 DuplicateHandle 함수를 이용해 핸들을 복사하면 된다.

7. 스레드 스케줄링, 우선순위, 그리고 선호도

요즈음의 윈도우는 선점형(preemptive) 운영체제여서, 특정 스레드가 프로세스를 독점할 수 없다. 윈도우는 매 20밀리초 정도(GetSystemTimeAdjustment 함수의 두 번째 매개변수로 반환되는 값)마다 모든 스레드 커널 오브젝트 중 스케줄 가능 상태에 있는 스레드 커널 오브젝트를 검색하고, 이 중 하나를 선택하여 스레드 컨텍스트 구조체 내에 저장된 레지스터 값을 CPU 레지스터로 로드한다. 이러한 작업을 컨텍스트 전환(Context Switch)이라고 한다.

스레드는 처음 생성될 때 CREATE_SUSPEND 플래그를 이용해 정지상태로 생성할 수 있다. 잡 오브젝트에 연결해야 한다거나 우선순위를 변경하는 등 스레드에 관련된 설정을 조작하려는 경우 이렇게 생성해야 한다. SuspendThread로도 스레드를 정지시킬 수는 있지만 동작중인 스레드를 이 함수로 멈추는 것은 위험하다. 사용하지 말 것(244p).

멀티 스레드 작업을 하다보면 Sleep(0)을 쓰게 될 경우가 많다. 이 케이스만 예전에 따로 포스팅 한 적도 있는데, Sleep(0)을 호출했을 때 스케줄 가능 상태인 다른 스레드가 있다면 그쪽으로 제어권이 넘어가지만 그렇지 않으면 호출한 스레드가 다시 스케줄되어 실행을 계속 하게 된다. 유사한 함수로 SwitchToThread 함수가 있다. 스레드 우선순위에 관련되어 약간의 다른 동작을 보인다.

하이퍼스레드 CPU에서 스핀 루프를 도는 경우 YieldProcess 매크로를 이용해 물리 코어를 공유하는 다른 프로세서로 제어를 넘기면 성능을 향상시킬 수 있다는 내용의 글이 있는듯 한데... 제대로 이해한건지 모르겠다(248p).

스레드 수행시간

Section 6에서는 프로파일러 만들 때 참고할만한 수행시간 측정 방법들이 설명되어 있다.

가장 기본적인 (1)GetTickCount 사용 방법 이외에, 해당 스레드가 소비한 시간만 얻어낼 수 있는 (2)GetThreadTimes함수, 그리고 정밀한 시간 측정에 가장 많이 쓰이는 (3)QueryPerformanceFrequency 함수에 대한 설명이 나와있다. 각자가 장단점이 있기도 하고, 시간 측정의 기본이 되는 프로세서의 주파수 값 자체가 일단 불안정 한 문제가 있기 때문에 모든 경우에 최적인 방법이 있는 것은 아니고 상황에 따라 적절한 방식을 선택하는 것이 좋다.

CONTEXT 구조체

스레드 컨텍스트의 값을 가져오거나 변경할 수 있는 Get/SetThredContext 함수가 설명되어 있다. 예전에 C++에서 코루틴을 만드는 한가지 방법으로 이 함수들을 이용해 컨텍스트의 값을 직접 갈아끼워 준다는 글을 본 것 같은데, 값을 읽을 때나 쓸 때 모드 해당 스레드는 정지해 있어야 한다. 즉 SuspendThread를 불러야 한다는 소리. 뭐야 그럼 맘대로 값을 조절해가면서 제어하기가 어려울 것 같은데.. 혹시나 코루틴을 만들어 쓰게 된다면 그냥 Fiber를 이용하는 것이 훨씬 낫겠다.

스레드 우선순위에 대한 설명은 나중에 필요할 때 읽어보면 될 듯 하다. 실제로 게임을 만들면서 우선순위를 조작하는 경우가 거의 없었고, 설명 중에도 크게 새로운 사실은 없다. 우선순위에 따른 동작을 가볍게 테스트 해보고 싶은 경우가 있다면 작업 관리자에서 특정 프로세스의 우선순위를 조작할 수 있으니 참고할 것.

선호도(affinity)

소프트 선호도 : 다른 조건이 모두 동일하다면 마지막으로 스레드를 수행했던 프로세서가 동일 스레드를 다시 수행하도록 하는 것. 윈도우의 기본적인 동작이다. 이렇게 하면 메모리 캐시에 있는 데이터를 재사용할 가능성이 높아진다.

하드 선호도(hard affinity) : 개발자가 어느 스레드를 어떤 CPU에서 수행할지를 제어하는 방식. SetProcessAffinityMask 함수를 이용해 설정할 수 있다.

보통 QueryPerformanceFrequency 함수를 이용해 민감한 시간측정을 하고자 하는 경우, 멀티 프로세서 머신이라면 좀 더 정확한 시간 측정을 하게 하기 위해 스레드가 하나의 CPU에서만 돌아가도록 처리하는 경우가 많다. 이럴 때 하드 선호도를 설정한다.

NUMA(Non-Uniform Memory Access) 구조의 머신에서도 메모리를 공유하는 같은 보드에 있는 CPU에서만 특정 프로그램을 실행하게끔 선호도 설정을 해주면 메모리 접근 성능이 훨씬 향상될 것이다. 이럴 때에도 하드 선호도를 지정해주면 된다.

지정된 CPU를 선호하지만 busy한 상태일 때는 다른 가용 CPU도 사용할 수 있게 설정할 수도 있다. 이럴 땐 SetThreadIdelProcess 함수를 사용하면 된다. 그 외에도 실행파일의 헤더 정보에서 선호도를 설정할 수도 있고(282p), 우선순위처럼 작업관리자에서 임시로 변경해 볼 수도 있다.

8. 유저 모드에서의 스레드 동기화

8장은 내가 발표했던 내용. 열심히 만든 PT로 대신한다.

9. 커널 오브젝트를 이용한 스레드 동기화

9장은 정리 생략 ㅜㅠ. 대부분 익숙한 내용이고, WaitFor*Object 함수들과 이벤트 객체, 세마포어, 대기 타이머 객체, 뮤텍스에 대해 설명하고 있다. 거의 대부분 작업하면서 많이 사용했던 것들인데, 대기 타이머 객체는 처음 알게 됐다. 직접 만들어서 쓰는 타이머 시스템보다 굳이 좋은 점을 꼽자면 다수의 스레드나 다수의 프로세스가 동시에 타이머의 통지를 받을 수 있다는 점인듯 한데(커널 객체니깐), 타이머를 그렇게 사용할 일이 있을까 싶기도 하고, 인터페이스가 생소해 그다지 끌리지 않는 감도 좀 있다 ㅠ 특수한 경우가 아니라면 타이머는 라이트하고 다루기 편하게 작성하는 게 더 좋아 보임.

 

책 내용이 적지 않아서, 4장을 한꺼번에 모아서 글을 적자니 제법 빡세구나... 천천히 조금씩 정리해야겠다. 정리하는 것보다 공부가 더 중요하니깐. 주객이 전도되면 안되지.

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

아꿈사 스터디 진도에 따라 책 내용을 개인적으로 정리할 생각입니다.

 

1. 에러 핸들링

1장은 내용이 그렇게 많지 않다. 윈도우 API가 에러를 반환하는 방식 (GetLastError류)과, 이와 유사한 방식으로 자신의 에러 코드를 정의할 수 있는 방법을 설명. 이보다는 가장 마지막에 나오는 MC.exe에 대해서 정리하려고 함. (뭐냐..)

예전에 visual studio 툴 자체에 대해서 공부하다가 코드를 컴파일 하는 cl.exe, 리소스를 컴파일 하는 rc.exe 외에 메시지를 컴파일 하는 mc.exe가 있다는 사실을 알고, 언젠가 기회가 되면 게임 수출할 때 로컬라이제이션 작업에 사용해 보리라 생각했던 적이 있다. 그리고는 그 다음 프로젝트 시작할 때 실제로 문자열 테이블 생성 작업에 쓰려고 본격적으로 리서치를 했던 적이 있지만 결국 사용되지 않고 drop 되었는데, 주된 이유가 두 가지였던 것으로 기억한다.

  1. 게임 클라이언트에 들어가는 문자열들의 최초 형태는 각 나라별로 엑셀파일에 정리되는 게 가장 좋기 때문에 mc를 사용한다고 해도 엑셀에서 mc 스키마로 한 번, mc에서 컴파일한 바이너리로 한 번 총 두 차례 변환을 거쳐야 하는 것이 부담스럽다.
  2. mc.exe가 입력으로 받아들이는 문자열 데이터는, 번역하고자 하는 모든 나라의 데이터들이 전부 같은 파일에 담겨야 한다. 앞서 이유에서 말한 두 차례의 변환과정을 자동화 할 때 이렇게 처리한다고 해도, 한 나라의 번역만 업데이트되도 다른 모든 나라의 언어 리소스를 함께 넣어 새로 빌드 하는 것이 부담스럽다.

혹시나 mc.exe를 게임 로컬라이징에 써볼까 하고 생각하는 분들은 참고가 되길 바란다.

2. 문자와 문자열로 작업하기

유니코드와 인코딩에 대한 이야기. 그 외 버퍼 오버런을 방지하기 위해 vs2005에서부턴가 새로 들어간 strsafe.h 헤더에서 제공하는 새로운 API들에 대한 이야기들. 윈도우에서 문자를 다룰 때 사용할 수 있는 동일한 기능의 함수가 여러 개 존재 하는데, 이들에 대한 우선순위를 확실히 정해주니까 좋았다.

  • 53p. strsafe에 대한 include구분은 다른 include 구문보다 반드시 뒤쪽에 위치되어야 한다. (컴파일 할 때 경고를 나타내기 위해서인 듯)
  • 기존의 c런타임 문자열 함수보다는 (strcpy) strsafe.h의 안전 문자열 함수를 사용하고 (strcpy_s), 문자열 잘림이나 남는 버퍼 공간 처리 등을 좀 더 세밀하게 다루고 싶다면 StringCch… 계열의 함수를 사용하라. (StringCchCopy) 하지만 애초에 문자열 잘림이 발생하지 않게 하는 것이 더 좋겠지.
  • 인코딩 변환에 쓰이는 MultiByteToWideChar, WideCharToMultiByte 함수의 상세한 설명. 멀티바이트 코드로 변환하다가 변환 불가능한 문자가 존재할 경우의 예외처리 등에 대한 설명이 있다.
  • 그 이에 IsTextUnicode (BOM 없는 문자열을 코드 패턴으로 어느 인코딩인지 추측하는 함수)나 언어 로케일을 포함해 문자비교를 할 수 있는 CompareString 같은 함수는 처음 알게 됨.

요즘은 문자열을 이렇게 저 수준으로 다루는 일이 많이 없지만.. 한 번 읽어두면 도움 될 내용이 제법 있었다.

3. 커널 오브젝트

커널 오브젝트를 제대로 공부한 것은 이번이 처음이다. 그냥 프로세스나 스레드 내지는 동기화 객체들 일부를 커널 오브젝트라고 부르더라.. 하는 것만 알고 있었을 뿐이었는데 이렇게 명확히 정리하니 속이 다 후련하다.

커널 오브젝트는 커널에 의해 할당된 간단한 메모리 블록이다. 커널 오브젝트에 대한 세부 정보들을 저장하고 있다. (커널 오브젝트는 실제 커널 내의 리소스에 대한 통계 정보 등을 접근하기 위한 인터페이스 정도의 역할이다.) 커널 오브젝트는 프로세스가 아니라 커널에 의해 소유되기 때문에 프로세스가 종료된다고 해서 생성한 커널 오브젝트가 반드시 함께 삭제되는 것은 아니다. 커널 오브젝트는 자신을 생성한 프로세스보다 더 오랫동안 삭제되지 않고 남아 있을 수 있다. 하지만 보통 내가 게임을 만들어 오면서 코딩하는 수준 안에서는 프로세스간에 커널 오브젝트를 공유하는 일이 없었기 때문에, 대부분 프로세스의 종료시점에 커널 오브젝트도 파괴된다.

커널 오브젝트의 종류를 모두 다 보여주는 WinObj라는 툴도 있으니 여기서 종류를 확인해 볼 수 있다. 코딩하면서 어떤 오브젝트가 커널 오브젝트인지 여부를 결정하는 가장 간단한 방법은 생성함수가 보안 특성을 지정하는 배개변수를 입력으로 받는지를 확인하는 것이다.(74p)

커널 오브젝트는 사용 카운트(use count)를 가진다. 이 값은 일반적인 레퍼런스 카운트(reference count)와 동일하게 동작한다. 여러 프로세스에서 참조하면 값이 올라가고, CloseHandle을 하면 값이 감소한다. 이 값이 0이 되면 커널 오브젝트는 파괴된다. 72p, 78p에 해당 내용이 설명되어 있고, 이후에 핸들 테이블에 대해 설명할 때도 몇 번 언급된다. 스터디 시간에 ‘커널 오브젝트는 프로세스보다 더 오래 남아있을 수 있다’는 특성 때문에, 제대로 해제해 주지 않으면 누수(leak)현상이 발생 하는 것이 아닌가? 하는 의문이 있었는데, 프로세스의 종료시점에 핸들 테이블에 지정된 커널 오브젝트의 핸들을 모두 Close하기 때문에 누수는 일어나지 않는다. (79p에 써있다.)

동일 애플리케이션이 여러 번 수행되는 것을 방지하기 위해 명명된 커널 오브젝트를 사용하는 것(92p)은 게임 클라이언트에도 종종 사용하는 기법이다. 이에 덧붙여 명명된 커널 오브젝트를 사용할 때 private namespace를 이용하여, 오브젝트 이름을 알더라도 권한이 낮은 프로세스가 접근하지 못하게 하는 방법이 소개되어 있다.

프로세스간에 오브젝트 핸들을 상속하거나 복사하는 방법도 설명되어 있는데, 나는 자주 사용할 것 같진 않다. 핸들을 복사할 때 특정 권한만으로 제한해서 복사할 수도 있다.

핸들로 표현되는 리소스라고 해서 모두 다 CloseHandle로 해제처리 가능한 것은 아니다. 101페이지에 예시가 등장.

4. 프로세스

4장이 내용이 엄청 길다.

114. VC++ 프로젝트 설정에서 /SUBSYSTEM 설정에 따라 콘솔 프로그램인지 윈도우프로그램인지가 결정되고 프로그램 entry point도 main/WinMain이 결정되는데, 이 설정란을 아예 비워주면 코드에 존재하는 함수를 보고 적절한 설정으로 자동 결정된다.

143. CreateProcess의 엄청난 인자 리스트를 설명하는 내용 중간에, 콘솔 프로세스가 새로운 콘솔 프로세스를 생성할 때 CREATE_NEW_CONSOLE 인자를 사용하면 독립된 별개의 콘솔 윈도우를 생성하게 할 수 있다는 설명이 있다. 알아두면 좋을 듯.

144. IsWow64Process 함수 : 프로세스가 64비트 운영체제에서 32비트 모드로 실행중인지 확인할 수 있다.

153. 스터디 시간에 많은 논란이 됐던 부분이다.

많은 개발자들이 프로세스나 스레드 핸들을 삭제하면 프로세스나 스레드가 종료될 것이라 생각하지만 이것은 절대로 사실이 아니다. 핸들을 삭제하는 것은 단순히 프로세스와 스레드의 통계적인 자료에 더 이상 관심이 없다는 사실을 시스템에게 알려주는 것일 뿐이다. 프로세스와 스레드는 자체적으로 종료될 때까지 계속해서 수행된다.

이것 때문에 커널 오브젝트의 사용 카운트는 레퍼런스 카운트와 다른 의미가 아니냐 하는 의문이 더 강해졌는데, 실제로 프로세스(스레드) 리소스와 프로세스(스레드) 리소스의 커널 오브젝트를 약간 별개로 두고 이해해야 한다. 커널 오브젝트가 파괴된다고 해도 그것이 가리키는 리소스가 항상 같이 파괴되는 것이 아니라는 이야기다. 책에서 '프로세스 커널 오브젝트의 파괴'와 '프로세스의 종료'라는 말이 나오는데, 파괴와 종료는 아마 원서에서 destroy, terminate일거 같은데 번역되면서 어감이 비슷해져 더 혼란스러운 감이 있다. 커널 오브젝트는 사용 카운트값이 0이 될 때 정확히 파괴(destroy)된다. 하지만 프로세스 자체는 커널 오브젝트가 파괴된 뒤에도 여전히 동작할 수 있으며, 155페이지 하단에 정리된 4가지 방법에 의해 종료(terminate)된다.

158, 159. 프로세스의 종료에 대해 이야기 하면서, 프로세스가 사용하던 모든 리소스는 환벽하게 정리된다는 내용이 다시 언급되고 있다. 커널 오브젝트, 사용자 오브젝트, GDI 오브젝트 등의 리소스 일체가 프로세스 종료시 자동으로 정리된다. 커널 오브젝트도 실수로 핸들을 close하지 않았더라도 따로 타 프로세스로 공유한 적이 없다면 반드시 파괴된다.

162. 커널 오브젝트의 사용 카운트를 공부하고 나면 당연히 이해할 수 있는 내용인데, CreateProcess로 자식 프로세스를 생성하자 마자 바로 자식 프로세스의 hProcess와 hThread 핸들을 닫아주는 것이 맞다. 이렇게 해도 자식 프로세스가 종료되는 것은 아니고, 접근할 일 없는 커널 오브젝트의 사용 카운트는 줄여 주는 것이 좋기 때문이다.

비스타 이후 도입된 UAC 시스템 에서의 권한 처리에 대한 설명들이 자세히 적혀있음. 클라이언트 배포 작업하면 볼 일이 많은데 나중에 참고할 것. API만 잘 이해하면 큰 혼동은 없으니 따로 정리하지는 않는다.

5.잡

잡 오브젝트의 존재를 처음 알았다. virtualization 소프트웨어를 개발할 때 많이 쓰이고, 크롬처럼 독립된 프로세스 단위로 프로그램을 만들 때도 쓰인다고 한다. 나중에 병렬처리를 스레드 단위가 아니라 프로세스 단위로 하게 되면 유용하게 사용할 수 있을 것 같다. visual studio도 빌드할 때 cl.exe를 별도 프로세스로 실행하는데, 책을 읽어보면 잡을 사용하고 있지는 않다. (197p) 아마도 legacy를 이어받아 개발했기 때문일것으로 예상되는데, 아마 vs2010에는 잡을 사용했을 것 같음.

간단하게 정리하면 잡 오브젝트란 여러 프로세스를 담아둘 수 있는 컨테이너 같은 개념이다. 프로세스를 잡에 묶어서 할 수 있는 대표적인 세 가지 작업은 아래와 같다.

  1. 권한 조절. 다른 프로세스에 접근하지 못하게 하거나 특정 리소스에 대한 접근을 제한할 수 있고, 사용할 수 있는 메모리가 cpu 타임도 조절할 수 있다.
  2. 통계 획득. job 안에서 실행되는 프로세스에 대한 메모리 사용량, io 횟수 정보, cpu 타임 등을 얻을 수 있다.
  3. 이벤트 통지. job 안에서 실행되는 프로세스의 주요 이벤트들을 핸들의 시그널 상태로 얻어낼 수도 있고, 자세한 여러가지 이벤트는 IOCP를 이용해 통지받을 수 있다.

이중 2번의 프로세스 통계 확인은 굳이 job 내의 자식 프로세스가 아니라 자기 자신의 정보를 구하는 것도 요긴해 보이는데, GetProcessTime이나 GetProcessIoCounters함수를 이용하면 얻을 수 있다. (198p)

Posted by leafbird 트랙백 0 : 댓글 1

댓글을 달아 주세요

  1. addr | edit/del | reply Favicon of https://devnote.tistory.com BlogIcon leafbird 2012.07.02 18:35 신고

    메시지 컴파일러의 사용은 아래 링크 참조.

    http://www.codeproject.com/Articles/4166/Using-MC-exe-message-resources-and-the-NT-event-lo