아키텍처로 특허 출원은 선행 기술이 있으므로

물건너 간게 확실.

자자. 현행 nimf에 심각한 문제가 있다.

nimf는 non-GUI, GUI 환경에서 동시에 작동 가능하도록 설계는 했는데, 구현상의 문제로 non-GUI 콘솔에서 사용하다보면 어느 순간 멈춤다.

이것을 분석해보니 이벤트루프에 문제가 발생했어.

단일 프로세스에 gtk 툴킷이 돌아감. gui는 플러그인 구조임. gui 없이 nimf를 돌리는게 가능하다는 얘기.

gui 이벤트 루프를 nimf의 cloop에 통합함. 스레드 방식 아님.

cloop가 콘솔 관련 io, gui 관련 io를 폴링함(kqueue, epoll, poll)

재현방법.

GUI 환경에서 ctrl + alt + f1 키를 눌러 non-GUI 콘솔 모드로 진입함

non-GUI 콘솔에서 한글 입력하다보면(이게 실제로 가능함 ㅋㅋ 내가 만듦 ㅋㅋ) 어느 순간 먹통됨.

디버깅 해보면 cloop가 콘솔 관련 io, gui 관련 io를 폴링하다가 gui 관련 io 폴링에서 무한 대기함.

non-GUI 콘솔로 전환한 상태이기 때문에 GUI 이벤트가 발생하지 않아, 거기서 무한대기하는 것임.

해결방법.

1. GUI를 별도의 프로세스로 만들고 IPC 하는 방법. 전통적인 방법임. 성능 저하 우려되고 프로세스 관리 방법이 필요함.

2. GUI를 별도의 스레드로 만들고 스레드간 통신하는 방법. eventfd 두개를 활용. 큐 두개를 통하여 쌍방향 통신이 가능함.

3. 호스트 스레드에서 GUI api를 직접 호출하는 대신 이벤트 큐1에 요청을 넣음.

4. GUI 스레드는 eventfd1를 감지하여 이벤트 큐1에서 요청 이벤트 꺼내서 처리함. 이 이벤트는

create window, update ui 같은 커스텀 이벤트임. GUI 툴킷에 정의된 이벤트가 아님.

5. GUI 스레드는 이벤트 처리 후 결과를 이벤트 큐2에 넣음.

6. 호스트 스레드는 eventfd2를 감지하여 처리 결과를 이벤트 큐2를 통하여 받음 ㅋㅋ

이러한 원리임.

GUI 스레드가 스레드로 돌고 있고 호스트 스레드에서 GUI 관련 io를 폴링하지 않으므로 GUI 루프가 GUI 관련 io가 없어서 무한대기하더라도 호스트 루프는 차단되지 않음.

즉, 디스플레이 서버(xorg, wayland  컴포지터 등)프로세스와 클라이언트 프로세스가 IPC 통신하는 방식을 단일 프로세스 내 2개의 스레드 방식으로 옮겨놓은거지 ㅋㅋㅋ

이거를 특허 출원하려 했었던 거임 ㅠㅠ