스카이넷은 공식Lua구현을 변형하였다(옵션), 하나의 특성을 추가했다. 여러 개의 Lua VM 이 동일한 함수의 원형을 공유할수있다. 동일한 skynet 프로세스중 대량의 lua VM을 기동했을시, 이 특성은 적지않은 메모리의 절약과 VM 시작시간의 향상을 가져온다.
이특성의 사용, 일반유저에 있어 투명하다. lua 의 보조 API luaL_loadfilex 를 수정하여, 직간접적으로 이 api를 사용하는 모든부분은 영향을 받는다. 예: loadfile, require 등. 파일 이름을 key 로 삼아, 같은 이름의 lua 파일이 로딩되면, 메모리상에 존재하는 함수의 원형으로 교체한다. 주: lua 함수는 함수의 원형과 0 또는 여러개의 upvalue의 바인딩으로 이루어져 있다.
loadString 은 영향받지않는다. 그래서 만약 당신이 한 개의 lua 파일을 여러 번 로딩할필요가 있다면 io.open 을 이용해서 파일을 열고 load 를 사용하여 로드한다.
코드 캐쉬 는 추가는 하되 삭제하지 않는 전략을 사용한다. 다시말해, 스크립트의 사본을 일단 로딩하면, 프로세스가 종료되기전에, 영원히 점용한 메모리를 해제하지않는다(재로딩되지도 않는다). 대부분의 경우에, 이것은 문제가 되지 않는다.
스카이넷은 또한 디버깅목적을 위해 캐쉬된 메모리를 삭제하는 인터페이스를 제공한다.
local cache = require "skynet.codecache"
cache.clear()
이렇게 코드캐쉬를 정리할수있다. 이 API 는 스레드안전하며, 이전버전의 데이터는 메모리에 남아있다(인용되고 있을수도 있다), 하지만 주의 해야한다. 단순히 캐쉬삭제에 의존하여 핫픽스를 진행하는 방안은 완전하지 않다. 핫픽스의 완전성과 이 특성의 도입여부와 관계없다. 왜냐하면 당신의 시스템이 루아 스크립트 덩어리를 로딩할때, 소스파일 업데이트에만 의존하고, 이 스크립트 로딩의 원자성을 보장할수 없기 때문이다 (어떤부분은 예전버전것, 어떤부분은 새버전의것)
주의, codecache.clear 는 그저 새로운 캐쉬를 생성한다 (API 이름이 오해를 부른다), 메모리를 해제하지 않는다. 그래서 이것을 여러 번 호출하지 말아야 한다. 만약 로드하려는 파일이 캐쉬에 영향을 받지 않는게 필요하다면, 올바른방법은 스스로 코드를 읽어드린후, loadstring 방식으로 스크립트를 로딩하는것이지, 로딩전에 codecache.clear 를 호출하는것이 아니다.
cache.mode(mode)
이 API 는 codecache 의 현재서비스의 모드를 변경한다. 모드는 ON/OFF/EXIST 가될수있으며 기본은 ON 이다.
-
모드가 ON 일때, 현재 서비스는 모든 로딩하는 Lua 스크립트 파일을 캐쉬한다.
-
모드가 OFF 일때, 현재 서비스는 Lua 코드를 재사용하려는 모든 행위를 막으며, 다른 서비스가 같은 파일이름을 로딩하더라도 마찬가지이다.
-
모드가 EXIST 일때, 다른서비스나 자신의 서비스에서 로딩된적이 있는 동일한이름의 파일을 로딩할때, 이전에 로딩된 카피를 사용한다. 하지만 새로 로딩되는 파일은 cache 를 진행하지 않는다. 주: 이는 skynet 자체가 cache 가 될수 있도록 한다.
API 파라메터가 공백이면, 현재 모드를 리턴한다.
주: 기본모드가 ON 인이유로. cache.mode를 처음으로 호출한 파일은 항상 cache 된다.