X.org 소프트웨어의 일부가 멀티스레드로 구성되어 있습니까?

X.org 소프트웨어의 일부가 멀티스레드로 구성되어 있습니까?

내가 아는 한 모든 명령줄 셸은 다중 스레드가 아닙니다. 특히 "작업 제어"(Control-Z bg, , 등)를 지원하는 쉘도 fg기능(예 fork: 신호, 파이프 및 PTY)을 통해 exec이를 수행합니다..

Emacs는 "동시에 많은 작업을 수행"할 수 있지만 멀티스레드도 아닙니다. (다시 말하지만, 외부 프로그램을 많이 포크하고 실행하며 신호, 파이프 및 PTY를 사용하여 이러한 외부 프로그램과 통신합니다.)

내 질문은 X11 프로토콜(X.org)의 기본 구현이 서버나 클라이언트 라이브러리의 Unix 스레드를 사용하는가입니다.

그렇다면 대략 언제부터(또는 그 조상인 XFree86이나 XFree86의 조상) 이 일을 시작했습니까?

답변1

$ ps -eLf
UID        PID  PPID   LWP  C NLWP STIME TTY          TIME CMD
root         1     0     1  0    1 19:25 ?        00:00:00 init [4]
...    
root      1699     1  1699  0    1 19:25 ?        00:00:00 /usr/bin/kdm
root      1701  1699  1701  8    2 19:25 tty10    00:13:10 /usr/bin/X :1 vt10 ...
root      1701  1699  1703  0    2 19:25 tty10    00:00:00 /usr/bin/X :1 vt10 ...
root      1706  1699  1706  0    1 19:25 ?        00:00:00 -:1
root      1707  1699  1707  0    2 19:25 tty9     00:00:02 /usr/bin/X :0 vt9 ...
root      1707  1699  1710  0    2 19:25 tty9     00:00:00 /usr/bin/X :0 vt9 ...
root      1713  1699  1713  0    1 19:25 ?        00:00:00 -:0
....

나는 그것이 당신의 질문에 대답한다고 생각합니다.

그래도 문제는 몇 가지를 함께 혼합하는 것 같습니다. 멀티스레딩은 fork()/ 를 사용하지 않는 것이 아닙니다 exec(). 스레드는 동일한 주소 공간을 공유하므로 다른 프로세스를 실행하려는 경우 동일한 주소 공간에 액세스하는 것을 원하지 않을 것입니다. 외부 프로그램(특히 언급한 셸에서)을 사용하지 않기로 결정한 경우 모든 기능을 다시 코딩해야 합니다.

멀티스레딩이 모든 문제를 해결하지는 않습니다. 실제로 이는 주로 병렬성 문제만 해결합니다. 확인위키 페이지좋은 간략한 개요입니다. 프로그램을 다중 스레드로 만든다고 해서 더 좋아지는 것은 아니며, 대부분의 경우 동기화 코드(존재하는 경우)의 버그로 인해 상태가 더 나빠집니다.

답변2

ES Raymond의 책에서 저자는 다음과 같이 인용합니다.

X 서버는 초당 수백만 개의 작업을 수행할 수 있지만 폴링/선택 루프를 사용하지 않습니다. 멀티스레딩 구현을 위한 다양한 노력은 좋은 결과를 얻지 못했습니다. 그래픽 서버처럼 성능에 민감한 서버의 경우 잠금 및 잠금 해제 비용이 너무 높습니다. ——짐 게티스

답변3

내가 이해한 바에 따르면 X11 자체는 다중 스레드 클라이언트를 방지하지 않으며 단지 Xlib에 제거할 수 없는 경쟁 조건이 있다는 것뿐입니다. 나는 출신이다XCB, 경험상 잘 모르겠습니다.XCB다중 스레드 클라이언트와 함께 사용하도록 설계된 Xlib 레이어 라이브러리입니다. 따라서 X11 클라이언트는 이벤트 기반, 거의 실시간 프로그램으로 작성되는 경향이 있는 것 같습니다. 스레드 클라이언트를 수행하지 않을 이유가 없습니다.

답변4

이것은 질문에 대한 직접적인 대답은 아니지만 내용을 명확하게 하고 설명이 너무 길다고 생각합니다.

제 생각에는 UNIX 스레드를 프로세스( )와 비교해서는 안 됩니다 fork(). 이 질문은 스레드가 어떻게든 프로세스를 대체한다는 것을 나타내는 것처럼 보이지만 사실은 아닙니다. 그것들은 모두 고유한 장점과 단점을 가지고 있으며, 어느 것을 사용할 것인지 결정하는 것은 궁극적으로 프로그래머의 몫입니다. 재구현도 마찬가지다.

스레드를 사용하는 것이 장점이 있다면 기본 도구가 다시 구현되거나 최소한 이를 위한 포크가 있을 것입니다.

개인적으로 저는 멀티프로세싱이 쉘링과 같은 작업에 더 나은 선택이라고 생각합니다. 왜냐하면 쉘이 많이 보호되기 때문입니다. 시작되는 프로세스는 미쳐버릴 수 있지만 쉘을 충돌시키지는 않습니다.

반면에, 예를 들어 신호는 모든 스레드에 전달되므로 스레드 쉘은 유틸리티 스레드에 의해 의도되거나 생성된 신호를 허용하는 동시에 유틸리티 스레드에 필요할 수 있으므로 이러한 신호를 전달할 수 있어야 합니다.

요약하자면, 멀티프로세싱을 사용하면 쉘과 쉘이 시작하는 프로세스를 더 잘 분리할 수 있고, 쉘에 의해 시작된 프로세스에 신호를 더 자유롭게 얻을 수 있으며, 아마도 내가 생각할 수 없는 다른 것들이 많이 있을 것입니다.

관련 정보