CumBuffer : accumulating byte buffer for c++

네트워크 TCP 프로그램인 경우에 임의 길이의 작은 데이터 조각을 수신해서 누적(버퍼링)시키다가 일정 길이가 수신되면 완전한 하나의 packet으로 보고 해당 데이터를 처리하는 경우가 꼭 필요하다. 지금까지는 그냥 new, calloc 등으로 데이터를 수신할때마다 동적으로 할당해서 기존 데이터를 복사하는 방식으로 해왔는데(동적할당 제거에 의한 성능개선이 크지 않았기에), 이번에 동적 할당없이 사용할 수 있는 버퍼를 구현해 보았다. 일종의 ring buffer 라고도 할수 있다.

https://github.com/jeremyko/CumBuffer

scott meyer c++ 은퇴

http://scottmeyers.blogspot.kr/2015/12/good-to-go.html

c++에 대해 관심을 가진 개발자라면 누구나 소장하고 있을 effective c++ 시리즈 의 저자 scott meyer가 c++활동을 그만하겠다는 글을 자신의 블로그에 올렸다. 예전과 비교할수 없을 만큼 활발한 커뮤니티 활동, 온라인 정보, 컨퍼런스등이 열리고 있는 상황에서, c++ 언어와 그 사용법을 설명하는 자신의 역활은 여기까지로 이미 충분하다고 느끼는 모양이다.

boost c++ library static link 컴파일 방법

막상 필요해서 찾다보니 잘 정리가 안되있어서 나름 정리해본다. boost 라이브러리를 이용해서 작성된 프로그램을 boost 가 설치 안된 환경에서 사용해야 하는 경우, static link 로 컴파일 해서 사용할수 있다.

.bash_profile 설정은 다음과 같다.

       export BOOST_ROOT=/CG/USER/kojh/MyApps/boost_1_57_0
       export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$BOOST_ROOT/stage/lib

static library 생성 

b2 옵션으로 다름처럼 주면, 기존에 동적 라이브러리가 위치하던 곳(boost 설치시 결정된)에

static 라이브러리 파일등이 생성된다.

b2 link=static

컴파일 

자신이 사용한 boost lib 를 static 하게 link 해서 컴파일 하면 된다( 다음 예는 boost thread 를 사용하는 경우이다).

g++ -pthread -O2 -I $BOOST_ROOT boostQueue.cpp -o boostQueue $BOOST_ROOT/stage/lib/libboost_system.a $BOOST_ROOT/stage/lib/libboost_thread.a -lrt

NBSPSC_Queue

배열을 이용한 Queue.
(Non Blocking Queue for Single Producer Single Consumer)

https://github.com/jeremyko/NBSPSC_Queue 
 

DisruptorCpp-IPC 가변길이 데이터 처리

앞서 Disruptor동작원리를 이용해서 IPC 로 동작하는 소스를 구현해봤는데 한가지 단점은 고정된 길이의 데이터를 미리 할당해서 링버퍼에 넣어두고 사용하는 방식이라는 점이었다. 만약 저장되는 데이터 길이가 가변적인 경우엔 이용할수 없는 단점을 보완해서 약간 수정된 버전으로 작성을 해보았다.

https://github.com/jeremyko/disruptorCpp-IPC-Arbitrary-Length-Data

간단히 설명 하지면 별도의 데이터 저장용 메모리를 할당하고, 링버퍼에는 데이터 저장위치만을 관리하는 방식이다. 

Disruptor 분석 및 c++ 로 구현해보기

java 하면 일단 좀느리다는 고정관념을 깰 만큼 고성능을 내세우는 Disruptor라는 존재에 개인적으로 관심이 생겨서 잠깐 내부를 살펴보게 되었다.
 
Disruptor 는 LMAX 라는 영국 외환 거래소에서 개발해서 사용중인 java기반의 inter thread messaging library 이다. Disruptor 라는 특이한 이름은 java기반으로는 고성능 메시지 처리가 불가능하다는 고정 관념을 깨는 녀석이라는 의미와, java 7 의 Phaser 가 했던 것처럼 Star Trek 영화에 나오는 Disruptor 라는 광선총 종류라고 한다.


이 글에서는 disruptor가 기본적으로 어떻게 동작하는지 알아 보고 c++ 로 구현해 보고자 한다.

여기서 설명한 내용이 구현된 소스는 다음 위치에서 참고할수 있다.

https://github.com/jeremyko/disruptorCpp-IPC

가변길이 데이터 처리를 위해서는 약간 변형된 다음 소스를 참고.
https://github.com/jeremyko/disruptorCpp-IPC-Arbitrary-Length-Data

UltraEdit 한글 버튼 메뉴 수정

업무용으로 주로 사용하는 UltraEdit 에서 프로젝트 메뉴의 파일설정, 한글 메뉴버튼 번역 잘못됐다고 알려줬더니 이번  22.10.0.12 업데이트에서 수정이 됬다. 볼때마다 불만이었는데 이젠 편안하게 메뉴를 볼수 있겠군.

nodejs 호스팅 비추천

c모 사의 node.js 호스팅 절약형  을 신청해서 사용하려 했는데, 
결국 내린 결론은 도저히 사용할만한 서비스가 아니란 거다.
heroku에서 아무 문제 없이 돌아가던것 간단한 app도 여기서는 안된다.
일단 package.json에 기입한 모듈들이 제대로 설치되는건지 그 로그조차 확인 할수 없다.
npm install시에 뭔가 문제가 생겨서 설치가 안된다면 그걸 사용자가 인지할수 있어야 하는데
그런것이 제공 안된다. 즉 사용자가 npm조차 실행할수 없다.
아마 git push시 돌아가는 스크립트에 npm install을 걸어놓은 모양인데

그나마 웹화면으로 제공되는 로그는, npm install의 로그가 아니라
앱을 실행시켰을때 나오는 실행 로그일뿐이라서 도움이 안된다.
아주 아주 간단한 express app을 node_modules까지 통째로 올리면 동작은 하지만, 
그렇게 단순한것 말고, 실제 쓸만한 앱을 만든다면 될지 말지 장담이 안된다.
아무리 월 500원짜리 서비스라고 해도 하다못해 터미널로 npm이라도 실행되게 해주고, 
그 로그라도 볼수 있게 해줘야지.. 답답한 이런 서비스를 돈받고 제공하는 이유가 뭔지 어이가 없을뿐이다.
몇번 전화 했다가 답답해서 죽는줄 알았습니다. 내 정신 건강을 위해서 그냥 포기.

AngularJS 게시판 accordion 스타일

요줌 web application 만드는 것에 재미를 느껴서 이것저것 기웃거리는 중이다.
오늘은 전에 만들어본 게시판을 single page application 이라는 형태에 부합시키기 위해서 accordion 형태로 변경해 보았다. angular ui bootstrap- accordion을 사용했다. 페이지 재로딩없이 모든 기능을 처리한려 구현 해봤는데.. 이러면 좀더 SPA 다워진걸까..^^

이 게시판의 소스는 아래에서 확인하세요.

https://github.com/jeremyko/simple_angularjs_bulletin_board

AngularJS : Seoul Dust Dashboard

Displaying current density of particulate matter(PM10) in seoul using AngularJS, Express.js

 https://github.com/jeremyko/SeoulDustDashBoard

앵귤러 보름만하면 나도 프론트엔드 웹개발자? ^^

서울시 대기환경 정보 사이트에서 주기적으로 데이터를 긁어와서  표와 챠트로 보여주게 하는 간단한 Web App을 만들어 보았다. 개발 하면서도 매우 재미 있었다.^^

AngularJS : Best practice, 'dot rule'

AngularJS 에서 model을 UI 에 바인딩 시키는 경우, 이른바 'dot rule' 이라고 하는 idiom 이 있다.

"ng-model을 사용 시 dot(.) 이 존재해야 한다. 그렇지 않다면 잘못하고 있는것이다"
"Whenever you have ng-model there’s gotta be a dot in there somewhere. If you don’t have a dot, you’re doing it wrong."

AngularJS Best Practices 에 나오는 내용이고 간단한 예제를 보이면서 설명하고 있다.
이 동영상에 나오는 예제와 동일한 맥락의 다음 예제를 살펴보자.

firefox 에서 JS Bin 이 제대로 표시가 안되는 경우엔 IE, chrome 을 사용해본다.

AngularJS : Controller들간 데이터 공유, $broadcast/$on or service?

AngularJS sharing data between controllers : $broadcast/$on or service?

예를 들어 A, B, C 컨트롤러간에 데이터를 공유해야 하는 경우가 있다라고 가정 해보자.
즉, A 컨트롤러가 변경시키는 어떠한 데이터를 다른 컨트롤러들에서 추적해서 화면등에 갱신이 필요한 경우라면 어떤 방법이 좋을까..
이러한 Controller들간의 데이터를 공유하는 방법에 대한 내용을 인터넷을 찾아보면
$broadcast, $on을 사용해서 구현한 경우를 자주 볼수 있다.
그런데 이곳저곳 살펴보고 내린 나름의 결론은 서비스를 사용하는것이 정석이란 것이다.
서비스의 본래 목적은 어플리케이션의 비지니스 로직을 담기 위한 장소이지만,  singleton의 특징을 활용, 이 서비스에 데이터를 보관하고 컨트롤러에서 inject하면 각 컨트롤러에서 동일한 데이터를 참조하게 할수 있는것이다.

firefox 에서 JS Bin 이 제대로 표시가 안되는 경우엔 IE, chrome 을 사용해본다.

AngularJS : Binding Primitive, Reference Type

AngularJS의 2 way-data binding 사용에 시행착오를 겪은 부분이 있어서 글로 남겨본다.

directive, expression 등을 사용하여 binding하는 경우 $watch가 생성되어 model의 변경을 감시하게 된다. 다음 예제를 한번 살펴보자.

예제1) 정상적으로 동작하지 않는 경우
버튼을 눌러봐도 값이 변경되지 않는다.

AngularJS 게시판

AngularJS(1.3.6)+ Express + mongojs 이용한 간단한 게시판

앵귤러 보름만 해보면 나도 프론트엔드 웹개발자^^

https://github.com/jeremyko/AngularJsBulletinBoard_PlainStyle
일반적인 형식

최근 Web front end 계의 대세라는 AngularJS에 흥미가 생겨서, 간단 게시판을 한번 만들어 보았다. Express app의 기본구조에 AngularJS의 처리를 추가한 형태이다. Express 는 일종의 Rest API 역활로서 mongodb의 데이터를 전송해주는 역활을 한다.

https://github.com/jeremyko/simple_angularjs_bulletin_board
accordion 스타일

Effective Object-C 2.0

며칠전 강컴으로 구입한 책이다. 책을 사서 처음 부터 읽지 않고 관심있는 부분부터 보는 습관인데, 지금까지 2개의 아이템만을 읽었을 뿐인데 번역의 질이 실망스럽다. 처음부터 완전 엉망은 아니지만, 100% 번역을 믿고 읽을 수준은 아니라서, 이런책이 원서보다 더 읽기 힘든책이다. 그리고 단지 2개의 아이템을 읽었을 뿐인데 편집상의 심각한 오류도 보인다. 도저히 무슨 내용인지 몰라 고민하다가 인터넷으로 원서내용을 볼수 있는 사이트를 알게돼서 직접 비교해보았다.

item 6 

41 페이지
'보통은 원자성은 필요없다. 더높은 레벨의 쓰레드 안정성을 보장하지 않기 때문이다'

Usually, atomicity is not required anyway, since it does not ensure thread safety, which usually requires a deeper level of locking.
--> 원자성이 스레드 안전을 보장 하는것은 아니기에 이를 사용할 일은 별로 없다. 일반적으로, 쓰레드 안전을 위해서는 몇 단계의 잠금이 요구되기 마련이다.
('더 높은' 이라는 말은 아주 이해하기 애매함)

_UIViewServiceInterfaceErrorDomain Code=3

Xcode 6.0.1 IOS8 simulator 에서 MFMailComposeViewController 클래스를 이용한 메일 전송시 다음과 같은 에러 발생됨.

viewServiceDidTerminateWithError: Error Domain=_UIViewServiceInterfaceErrorDomain Code=3 "The operation couldn’t be completed. (_UIViewServiceInterfaceErrorDomain error 3.)" UserInfo=0x7fcb9ca007a0 {Message=Service Connection Interrupted}
2014-10-02 22:10:41.518 PushUpCounter[1241:22189] <MFMailComposeRemoteViewController: 0x7fcb9c86aa70> timed out waiting for fence barrier from com.apple.MailCompositionService

이게 IOS8 시뮬에서만 발생되는 버그인데, 실제 device로 테스트 시에는 정상 동작한다.
애플이 좀 급하게 IOS8 SDK를 내놓은 모양이네 ..^^

ios8 업데이트

어제 애플이 ios8 업데이트를 배포했다고 바로 이런 메일이 도착.
음..버그를 잡아야되는데...
이번엔 개발자 등록도 연장 안했는데.. 좀 고민되네...
도의적 책임을 지고 끝까지 A/S를 하느냐 마느냐...

20141009 업데이트
오늘 1.3.1 업데이트가 스토어에 올라감.

내가 본 거지같은 소스들 - sizeof 와 구조체 패딩

지금까지 일한곳들에 존재하는, 거지 같은 소스들을 유지, 보수하면서 느낀점들을 정리한다.  

sizeof 와 구조체 패딩

결론만 먼저 얘기하면, 구조체 크기를 임의로 가정해서 이 수치를 가지고 연산하지 말라는 것이다. 구조체를  다룰때 네트워크 연동등이 아니라면, 일반적으로 패딩 바이트에 대해 신경 쓸일은 없다. 그런데 네트워크 연동이 아니더라도 구조체 크기를 임의로 판단, offset 으로 멤버에 접근을 시도하면 문제가 될수 있다는 것을 아래에서 보여주고 있다.

먼저, 다음과 같은 형태의 데이터를 빈번하게 파일에 쓰는 경우를 생각해보자.

#define MAX_DATA_SIZE  2048

typedef struct __FileBlock
{
    char     strData1 [2];
    int      nNumber1  ; //4byte
    int      nNumber2  ; //4byte
    int      nNumber3  ; //4byte
    char     strData2 [50];
    char     strData3 [MAX_DATA_SIZE];
} ItemFileBlock;

그리고 이 구조체 변수에 값을 채우고 파일에 그대로 저장하는 경우를 위한 함수를 하나 작성했다,

bool SaveDataToFile(ItemFileBlock* pstFileBlock)
{
    //m_clsFile 는 파일 I/O 를 담당하는 객체
    //구조체를 sizeof(ItemFileBlock) 크기만큼 파일에 저장.
    if( !m_clsFile.WriteRecord((char*)pstFileBlock, sizeof(ItemFileBlock)))
    {
        return false;
    }     
    return true;
}

그리고 이함수를 이용해서 데이터를 저장.

ItemFileBlock stFileBlock;
//이제 stFileBlock 의 항목을 채운다. 
//.....

//pData3 는 이미 사용자의 정보를 가르키고 있는 포인터 이다.
memcpy(&stFileBlock.strData3, pData3, MAX_DATA_SIZE); //흠 복사 할 게 좀 많네  

//함수 호출
if(!SaveDataToFile(&stFileBlock)){
    ....
}

여기까지는 좋다. 뭐 그냥 파일에 구조체 크기만큼 저장하는거니까 이걸로 OK.

그런데 이 개발자는 strData3 항목에 계속 데이터를 복사하는게 마음에 걸린 모양이다. 이미 이 항목에 저장할 데이터의 포인터(pData3)를 가지고 있어서, 굳이 복사를 안해도 될것 같아 성능 향상(실제로 성능이 향상될거 같지는 않다. file I/O가 추가됬으니 - -)을 목적으로 SaveDataToFile 함수를 다음처럼 수정했다.

//이젠 strData3에 저장될 데이터를 포인터로 받는다.
bool SaveDataToFile(ItemFileBlock* pstFileBlock, char* pData3)
{
    //2번에 나눠 파일에 저장. 한번은 strData3 이전 데이터
    // !!! sizeof(ItemFileBlock)-MAX_DATA_SIZE 이것은 ?!
    if( !m_clsFile.WriteRecord((char*)pstFileBlock, 
                              sizeof(ItemFileBlock)-MAX_DATA_SIZE) )
    {
        return false;
    }
    
    //strrData3은 여기서 저장된다  
    if( !m_clsFile.WriteRecord((char*)pData3, MAX_DATA_SIZE)) {
        return false;
    }

    return true;
} 

//그리고 실제 호출시에는 다음처럼 strData3에 불필요한(?) 복사를 생략하여, 

//값을 채우지 않는다.
ItemFileBlock stFileBlock;
//stFileBlock 의 항목을 채운다. 
.....
.....
//memcpy(&stFileBlock.strData3, 사용자의정보, MAX_DATA_SIZE); //생략!

//함수 호출
if(!SaveDataToFile(&stFileBlock, pData3)){
    ....
}

sizeof(ItemFileBlock)-MAX_DATA_SIZE

 
구조체 크기에서 MAX_DATA_SIZE 만큼 빼면 strData3 항목의 시작위치가 될것이라는 가정..

이렇게 구조체의 선언만 보고, 임의로 구조체 크기를 가정하고 거기에 offset연산까지 적용해서 어떤 구조체 멤버에 접근하려는 시도가 문제되는 부분이다. 원래 작성자의 의도는 구조체의 strData3 이전 데이터를 먼저 파일로 저장후, 이어서 실제 사용자 데이터 부분을 저장하려던 것이었다. 불필요한 복사를 생략하고, 이미 구해진 데이터의 포인터를 활용해보자는 목적이었는데, 문제는 sizeof(ItemFileBlock) 이 돌려주는 길이는 컴파일러에 의해 암묵적으로 삽입된 패딩 바이트를 포함하고 있다는 것이다.

offsetof 매크로를 이용, 각 구조체 멤버의 offset 위치를 구해보자. 

#define MAX_DATA_SIZE  2048
typedef struct __FileBlock
{
    char     strData1 [2];
    int      nNumber1  ; //4byte
    int      nNumber2  ; //4byte
    int      nNumber3  ; //4byte
    char     strData2 [50];
    char     strData3 [MAX_DATA_SIZE];
} ItemFileBlock;

void testFunc()
{
    printf("sizeof(ItemFileBlock)[%d]\n",sizeof(ItemFileBlock));
    printf( "offsetof(strData1)  =%d\n",offsetof(struct __FileBlock, strData1 ));
    printf( "offsetof(nNumber1)  =%d\n",offsetof(struct __FileBlock, nNumber1 ));
    printf( "offsetof(nNumber2)  =%d\n",offsetof(struct __FileBlock, nNumber2 ));
    printf( "offsetof(nNumber3)  =%d\n",offsetof(struct __FileBlock, nNumber3 ));
    printf( "offsetof(strData2)  =%d\n",offsetof(struct __FileBlock, strData2 ));
    printf( "offsetof(strData3)  =%d\n",offsetof(struct __FileBlock, strData3 ));
}

//실행 결과
sizeof(ItemFileBlock)[2116]
offsetof(__FileBlock,strData1)  =0
offsetof(__FileBlock,nNumber1)  =4
offsetof(__FileBlock,nNumber2)  =8
offsetof(__FileBlock,nNumber3)  =12
offsetof(__FileBlock,strData2)  =16
offsetof(__FileBlock,strData3)  =66

즉 다음처럼 패딩 바이트가 삽입됨을 알수있다.

typedef struct __FileBlock
{
    char     strData1 [2]; //offset 0
    char     padding  [2]; //offset 2 
    int      nNumber1  ;   //offset 4     
    int      nNumber2  ;   //offset 8    
    int      nNumber3  ;   //offset 12    
    char     strData2 [50];//offset 16    
    char     strData3 [MAX_DATA_SIZE]; //offset 66
    char     padding  [2]; //offset 2114
} ItemFileBlock;

sizeof(ItemFileBlock) 는 모든 구조체 멤버의 실제 길이를 합한 길이 2112 가 아니고, 

컴파일러에 의해 삽입된 패딩 바이트를 포함한 2116을 리턴한다.

그래서 sizeof(ItemFileBlock)  - MAX_DATA_SIZE 이값은 2116-2048 = 68이 되버린다.

이것이 왜 문제가 되는가? 
위 파일 저장 함수에서 2번에 걸쳐 저장을 할때, 처음 쓰기에서는 68 바이트를 저장하고있다. 이렇게 되면 실제 저장되어야할 길이 66 바이트보다 2 바이트를 초과해서 쓴 꼴이 된다. 그리고 2번째 파일 쓰기에서는 2바이트가 밀린 상태로 나머지 strData3을 쓰게 된다. 이런식으로 2번에 걸쳐 파일에 저장시, 실제 파일에 저장되는 구조체의 데이터는, 구조체를 한번에 저장할때와 다른 모습으로 비정상으로 저장된다. 

 
* 정상적으로 구조체가 저장된 경우 

|---------strData1~2----|---------------strData3--------------|---padding----|
          66 bytes                      2048 bytes                2 bytes

* 비정상적으로 구조체가 저장된 경우 

|---------strData1~2--------------------|---------------strData3-------------| 
          68 bytes                                      2048 bytes

이처럼 잘못 저장된 데이터를 다시 파일에서 읽어들이는 경우는 어떨까? 
파일에서 읽어 이를 구조체로 변경하는 경우, strData3 데이터 시작부분이 2 byte가 밀려 있으리란것을 예상할수 있다 (실제로 당하니 멘붕. 데이터를 분명 썼는데 읽으면 안보임 - -).  이것을 해결하기 위해서는 구조체 pack 혹은 명시적으로 패딩 바이트를 삽입하는 방법등이 있는데 그것은 생략한다. 구조체는 일반적인 방법(멤버 참조)으로 쓰는 경우는 문제 없다. 하지만 위에서처럼 offset 으로 멤버의 위치를 유추하려는 시도를 할때는 반드시 암묵적 패딩 바이트를 고려해야만 한다.

  

g++ std::thread -pthread option?

std::thread 를 이용한 프로그램을 리눅스 환경에서 g++ 을 이용, 컴파일 하는경우 -pthread 옵션이 필요하다. 
다음과 같은 샘플 프로그램이 있다고 해보자.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

//std_thread_test.cpp #include <thread> #include <iostream> void thread_func() { std::cout<<"hello, I am a thread!"<<std::endl; } int main() { std::thread t(thread_func); t.join(); }

컴파일시에 다음처럼 -pthread 옵션을 설정해야한다.

g++ -std=c++11 -pthread -o std_thread_test std_thread_test.cpp

옵션을 주지 않는 경우엔 컴파일은 되지만 실행시 core dump가 발생한다.
사용된 g++의 버전은 g++ 4.8.2 으로 c++11 의 기능을 대부분 지원한다.
그렇다면 의문점이 생긴다. c++11 을 지원한다는 g++에 왜 -pthread 란 옵션이 필요한가?
언어 차원에서 지원된다는데 왜 pthread 라이브러리 이런게 보이는건지..?

좀 생각해보니 spec과 구현의 문제라는걸 알게 되었다.
c++11 의 thread specification 을 g++에서는 기존의 pthread 라이브러리를 사용해서 구현한것일뿐이다.(이건 사기?). 
이건 g++ -v 을 실행해보면 확인할수 있다.

Thread model로 posix 를 사용한다 (좀 허무)

장당 500원만 받아요

장당 2000만원에 비하면 거저.