라이푸

역시나 간단하게 해결을 볼 수 없었다.

기존에 라이브러리를 공유시키는 작업을 완료했더니 이제는 개별적인 데이터를 소유해야 한다는 문제가 있었다.

정확하게 말하면 lua_newthread가 전역적으로 선언한 테이블은 공유가 가능했다.

문제는 child에서 어떤 전역변수나 테이블을 선언하게 되면 이또한 모든 루아스테이트가 공유한다는 것이었다.

local로 선언하여 어떻게든 인스턴스를 흉내낼려고 했으나 어플리케이션단에서 엑세스 할 수 있는 방법이 없었다.

스크립트를 대대적으로 수정하지 않는한 불가능했다.

일단 메타테이블을 사용해서 클래스를 만들고 이를 상속시켜 인스턴스를 만들어 개별적인 데이터를 소유할 수 있게 하였다.

동시에 클라이언트도 많은 부분을 수정했다.

그리고 빌후 실행해 보았다.

스킬자체가 없어졌다-_-

일단 루아쪽은 계획한되로 라이브러리를 공유하고 개별적인 데이터를 갖게되었다.

내일중으로 디버깅걸고 수정후에 평가를 받아야 한다.

스크립트쪽에 대대적인 수정이 있을텐데 푸가 정확한 판단하을 하고 확실한 검증을 해야한다.

한번 요청으로 대대적으로 수정되기 때문에 이를 번복할 수 가 없다.

이제 작업의 끝이 보이는듯 하다:-)

2주가까이 디버깅만 했다.

문제는 lua_newthread로 child를 생성한 뒤에 바인드한 일부 함수를 호출 하지 못하는 문제가 발생했다.

일단 바인드된 부분을 살펴 보았지만 이상이 없었다. 국지화된 코드에 이상이 있을리 없었다.

인자 문제라 생각해서 루아 스택덤프를 떠봐도 이상이 없었다.

혹시나 메모리크래쉬가 의심되어 힙쪽 메모리를 살펴봐도 전혀 이상이 없었다.

그리고 도움말, 예제, 위키를 봐도 도움될만한 것들은 없었다.

이후부터는 죽을 맛이었다.

수많은 가설을 세우고 테스트를 반복했지만 원인을 알 수가 없었다.

그러다 문득 숲은 보고 산은 못보고 있는 듯한 느낌이 들었다.

그래서 시작부터 로딩쪽 전체를 분석하기 시작했다.

그러다 특정 시점부터 문제가 발생한다는 걸 알았다.

이후부터는 루아파일을 이잡듯이 뒤지기 시작했다.

그때 딱 한줄이 눈에 들어왔다. 

Info = { }

푸는 이 악마-_- 같은 한줄로 모든 문제의 원인을 파악할 수 있었다.

Info는 바인드된 함수의 라이브러리 이름이었다. ex) Info.GetType( Unit )

lua_newthread로 생성한 child들은 독립적인 스택을 보유하게 된다.

신기한건 child에서 로드된 라이브러리 이름으로 뭔가 선언하게 되면 그것이 main 루아스테이트에 영향을 미친다는 것이다.

즉 이후에 생성된 child들은 모두 문제가 발생하는 것이다.

이걸로 2주동안 무한 디버깅을 했구나...

이제 빠르게 마무리 해야겠다.

lua_newthread

[-0, +1, m]

lua_State *lua_newthread (lua_State *L);

Creates a new thread, pushes it on the stack, and returns a pointer to a lua_State that represents this new thread. The new thread returned by this function shares with the original thread its global environment, but has an independent execution stack.
There is no explicit function to close or to destroy a thread. Threads are subject to garbage collection, like any Lua object.

왜 이걸 몰랐을까?

루아스테이트는 기본적으로 하나의 존 같은 개념으로 서로의 메모리 공유는 되지 않는다.

이건 루아스테이트만 놓고 봤을 때의 이야기다.

그러나 lua_newthread로 생성된 루아스테이트는 인자로 들어가는 루아스테이트와 메모리를 공유하게 된다.

메모리를 공유하다 보니 테이블은 물론 바인딩된 함수까지도 그되로 공유된다.

푸가 리뷰를 좀더 정확하게 했다면 좀더 빠르게 작업을 진행했을 것이다. 

그런데 무식하게 만들고 있었다.

아마도 스크립트쪽 변경은 거의 없고, 클라이언트쪽은 많은 수정을 해야 할거 같다.

무사히 작업이 완료되면 그간 문제가 있던 로딩쪽과 메모리쪽은 매우 큰 향상이 있을 듯하다.

루아를 luaL_dofile해도 해당 루아스테이트로 글루나 팅커를 사용한 내용은 포함할 수가 없다.

아마도 단순하게 루아파일에 있는 텍스트 원문만 가져오는 듯하다. 이건 패스하자.

처음 생각은 스크립트를 전혀 고치지 않고 클라이언트쪽에서 해결을 볼려고 했다. 

그렇게 할려면 매번 루아파일을 파싱해야하고 wrapper를 만드는데 소모되는 메모리도 무시할 수 없었다.

그래서 스크립트에서 호출하는 함수명만 변경하는 쪽으로 정책을 잡았다.

일단 스크립트 쪽에서 호출은 "Global_Func( "G_Sum", "P", g_Unit )" 이런식이 된다.

함수자체는 C++에서 루아쪽으로 바인드 시켰다. 

사이클이 어플리케이션쪽으로 오게되면 해당하는 루아 스테이트에서 G_Sum이라는 함수를 바인드한다.

이후에 팔라미터를 분석하여 매개번수들을 Push하고 PCall하게 된다.

이제부터가 지옥의 문이 열리기 시작하는건데-_-;

단순 int, float, string 뭐 이딴건  상관없는데, 루아쪽에서 생성한 데이터타입이 문제다.

이건 어떻게 push하고 return 해야하는지 좀 고민해야봐야 한다.

지금 생각하고 있는건 어차피 UserData를 사용하고 있으니 모든 리턴값을 글로벌 변수에 밀어 넣을 생각이다.

너무 쿨한 생각인가-_-; 

그런데 그렇게 하지 않으면 클라이언트쪽에서도 데이터 형태를 알고 있어야 하는데 방법이 있는지 모르겠다.

내일 중간 평가 받고 이 문제를 해결하고 프로젝트에 적용해볼 생각이다.

라이푸에 눈에는 보인다... 지옥에문이... 이제곧 활짝 열린다-_-

계속해서 악몽을 꾸고있다.

꿈 자체가 너무 선명하고 매번 무엇가에 대한 결과를 보여준다.

문제는 푸가 원해서 보는게 아니라는 것이다.

악몽이여~ 강철멘탈 푸한테 도전하는가?

어떤 심리가 작용해서 이러는 걸까?

그런데 갈수록 강도가 세지는데... 이거 반칙아님-_-