이번에 남들 다쓰는 file locking 메커니즘을 이용하여 nimf 를 딱 1개만 실행되도록 고쳤습니다. 원래 전부터 nimf 가 딱 1개만 실행되었는데, 보안 문제 때문에 unix abstract socket 을 unix path 소켓으로 변경하면서 자주 2개 이상씩 실행되더군요. 아무튼 고쳤습니다.
당장 고쳐야 하는 부분은 다 고쳤습니다.
그럼 이제 또 썰을 풀어보려 합니다.
입력기 기술은 왜 이렇게 낙후되었는가?
상업용 유닉스가 유행하던 시절보다 왜 오히려 퇴보했을까?
저도 그점이 참 궁금합니다. 한번 추측을 해보겠습니다.
과거 90년대는 유니코드가 유행하지 않았습니다. 현재는 유니코드를 사용하므로 그점에서 입력에 있어서 편리해진 부분이 있는데 nimf 를 제외하고 ibus, fcitx, uim 등의 리눅스쪽 입력기들은 아직 90년대 솔라리스에 있던 다국어 / 한글 입력기보다 UI 도 구리고 (진짜임) 왜 그렇게 오작동이 심한지 모르겠네요. ibus 의 한글 버그는 10여년간 아주 악명 높고, fcitx 의 설정창은 이건 완전 던전 깨는 분위기입니다. 게다가 드보락 키보드 쓰는 사람은 fcitx 죽었다 깨어도 못습니다. fcitx 에 버그 때문입니다. fcitx 로는 영문 드보락 + 한글 입력 이게 안 됩니다. 그러니까 그게 버그죠 !!! 그리고 uim 은 거의 사용해보지 않았는데 tray 작동시키는게 이것도 완전 던전이에요. 마찬가지로 설정하는 UI 는 던전 깨는 것 같아요.
우리 많이 사용하는 프로그램들 있어요.. 그쵸? 작은 프로그램들도 많습니다. UI 어떤가요? 깔끔하지 않나요? 즉, nimf 제외하고 입력기들이 이렇게 구린거에요. 발전이 없다고요.
과거 유닉스 시절에는 입력기가 구리면 유닉스 팔아먹는데 문제가 있기 때문에 입력기가 좋았는데, 아마 그런 이유도 있을 것 같아요.
이번에 nimf 의 구조를 대강 설명 드릴께요.
nimf 는 클라이언트 / 서버 구조의 입력기 프레임워크에요.
입력기가 통신하네... 다른 입력기도 통신하던데 이거 문제 있는거 아냐?
아뇨.. 문제 없어요.. 동기화 방식이라 함수처럼 작동합니다. 진짜에요. !!
동기화 통신에서 문제되는데 deadlock, race condition 이게 문제가 되는데, 이게 뭐냐고요?
한마디로 컴터 먹통 되는거에요. nimf 도 당연히 그런 문제가 있었는데 개발 초기에 다 잡았어요 ^^ 참 기쁘죠? 제가 괜히 호구처럼 패키지를 뿌리는게 아니랍니다. 사용자 많이지면 다양한 보고가 들어오고 품질 향상에 도움이 되기 때문에 패키지를 많이 뿌렸던거에요.
지금은 자동화 PPA라 제가 고생할 것도 없어요 이히히히~
암튼 개발 초기인 2015년 말에 deadlock, race condition 문제가 모두 해결 되었답니다.
아까 말씀 드리길 nimf 가 클라이언트 / 서버 구조라고 했죠?
클라리언트/서버 구조라고 해서 다 똑같은 클라이언트 서버가 아니랍니다.
ibus, fcitx 들은 unix socket 놔두고 DBUS 로 복잡하게 만들고 비동기로 통신하는 괴상한 방식으로 작동합니다.
클라이언트 ---------- 메인서버 ------------ 엔진 서버 1
XIM서버 엔진 서버 2
wayland서버
후보창(candidate window,한자입력할 때 튀어나오는 창) 서버
제 기억으로는 서버가 참 많았던 같은데 아직도 이런 구성으로 돌아가는지는 모르겠네요.
위에 보면 저게 무척 비효율이에요. 통신이 너무 많이 발생한다는 거죠.
모두다 통신으로 이루어진다는 거에요.
만약에 한국어, 중국어, 일본어를 사용한다면
메인서버, XIM 서버, wayland 서버, 한국어 서버, 중국어 서버, 일본어 서버, 후보창 서버, 상태 알림 서버가 돌아갈거에요.
ibus 의 경우 서버가 한 8개 정도 돌아갑니다. 진짜에요.
fcitx 의 경우도 대동소이하고, uim 은 잘 모르겠는데, 상태 알림 서버가 돌아갑니다. 아주 진짜.. ibus, fcitx, uim 등을 보면 많은 서버(데몬)이 작동합니다.
절대 거짓 과장이 아닙니다. 우리가 익히 알고 있는 입력기들이 이렇게 문제가 많으니 사용자분들이 지금까지 고생하고 계신 겁니다.
nimf 는 서버가 오로지 1개입니다. 사용자 1명당 서버 1개가 돌아갑니다.
서버 1개에서 XIM, Nimf, Wayland 이것을 다 처리합니다. 통신이 최소화되어 속도가 빠릅니다.
클라이언트 ---- 서버1개(xim, Nimf, Wayland) ----- 데스크탑 패널의 상태 알림(표시기).
이렇게 구성되어 있습니다. 전에는 표시기를 서버(데몬)로 돌렸었는데 작년에 표시기를 모듈로 만들어서 서버 내에 포함시켜 버렸죠.
후보창(한차 나오는 창)도 서버 모듈(플러그인)로 되어있습니다.
그래서 소스코드 양이 적습니다. 다 입력기보다 1/3, 1/4 정도의 코드로 같은 일을 수행합니다. 정교하게 설계되어 중복코드가 적다는 의미.
nimf 의 장점은 또 있습니다.
client im api, candidate api, server api 를 제공합니다. 단지, 제가 시간이 없어 다듬지 못하고 문서화를 못했을 뿐이지 타 어플에서 nimf api 를 끌어다 쓸 수 있게 되어 있습니다.
그리고 nimf 는 C언어, glib 로 만들었기 때문에 이식성이 우수합니다.
간단히 말해서 뭔말이냐면 python, ruby, js 등이 동적 언어 바인딩이 손쉽게 됩니다. 그것은 glib 에서 제공해주는 기능입니다.
그리고 장점이 또 있습니다.
싱글톤 모드로 작동된다는 거에요. 그래서 메모리 소비량이 적습니다.
싱글톤 모드가 뭔지 모르시죠? .. 아 그걸 어떻게 설명해야 하나.
전통적인 라이브러리 방식의 입력기를 보면 말이죠...
gedit 를 실행시키면 gedit 가 입력 객체를 7개를 만듭니다.(gedit 버그)
일반적인 방식이라면, 입력 객체를 7개 모두 만들어야 하는데,
(라이브러리 방식으로 싱글톤 방식으로 입력 개체를 1개 만들 수 있는 방법이 있음)
통신 방식을 이용하면 입력 객체를 1개만 만들어서 공통으로 사용할 수 있습니다.
이게 싱글톤 방식이라는 거에요.
한국어 1개당 2메가 잡아먹는다고 할 때, 라이브러리 방식은 7 * 2 = 14메가 잡히고,
통신 싱글톤 방식은 1 * 2 = 2메가 잡힌다고 보면 됩니다.
그런데 중국어, 일본어도 같이 사용한다고 하면, 각각 10 MB 소비한다고 할 때,
라이브러리 방식에서는
7 * 2 + 7 * 10 + 7 * 10 = 154 MB 소비하고, (예를 들어 그렇다는 겁니다.)
통신 싱글톤 방식에서는
1 * 2 + 1 * 10 + 1 * 10 = 22 MB 를 소비합니다. (예를 들어 그렇다는 겁니다.)
응용 어플을 10개 정도 실행시키면
라이브러리 방식은 1기가 잡어먹고, 통신으로 구현한 싱글톤 방식은 22메가 잡아먹는다고 보시면 됩니다. 통신 방식의 싱글톤 방식은 언어 엔진을 공유할 수 있어서 어플 100개를 실행해도 어플 1~2개 분량의 수십 메가 정도 메모리만 소비합니다. (예를 들어 그렇다는 겁니다. 진짜로 2~30 메가 소비하지는 않아요.) 라이브러리 방식으로는 1기가 넘어 갑니다. 그래서 다국어 입력기가 통신 방식으로 가고 있는 겁니다.
원래는 싱글톤 방식이 아닌 멀티플 인스턴스 방식으로 작동해야 정확한 것입니다.
간혹 어떤 어플은 싱글톤 방식으로 입력 버그가 발생하기 때문에, nimf 는 정확하게 작동하는 멀티플 인스턴스 방식도 제공합니다.
사용자분이 원하면 멀티플 인스턴스 방식으로도 작동시킬 수 있습니다.
멀티플 인스턴스 방식으로 동작하게끔 옵션을 주면 통신은 통신인데 라이브러리 방식처럼 결과가 나오도록 돌아가게 됩니다.
꿈의 입력기... 제가 그동안 개뻥치는 줄 아셨죠? ㅋㅋㅋ
타 입력기는 nimf 를 흉내조차 낼 수 없습니다.
nimf 는 우리가 그동안 보아온 입력기들의 미래입니다.
그래서 nimf 가 꿈의 입력기라는 것입니다.
댓글 없음:
댓글 쓰기