setjmp(), longjmp() 는 소스전역에 대한 goto 문이라고 보면됩니다.
setjmp() 가 레이블이 되고.
longjmp() 가 goto 문이 되죠.
goto 과 다른 것은 setjmp() 시 현재의 스택상황을 저장하고
longjmp() 시 그때의 스택상황으로 복원하는 겁니다.
SMP 의 성능을 최대한 끌어 쓸 수 없다는 것은 맞습니다만, 하부의 실질적인 I/O는 SMP 사용을 알아서 커널이 할테니까 조금은 이득이라고 생각하구요. 이걸 분배 못하는 OS도 있겠지만 다른 프로세스들도 돌고 있을테니...
그 동기화 때문에 이런 류의 쓰레드 라이브러리를 쓰기도 합니다. 일반적인 선점형 쓰레드 라이브러리는 언제 컨텍스트 스위칭이 일어날 지 모르는 상황이라 엄청난 동기화 객체가 난무하게 마련인데, 이런 라이브러리는 그야말로 io 동작 혹은 지정한 함수 외에는 스위칭이 일어나지 않는 것을 확실히 할 수 있으므로, 프로그래밍이 한결 쉬워집니다.
아마 일반적인 사용자레벨 쓰레드 라이브러리와 혼돈을 하신 것 같은데,
StateThread는 그런 문제들, 즉 다중 CPU에서의 확장문제나 이런 것들을
해결하기 위해서 나온 것입니다. C10K문제를 아마 아실텐데, 제가 고객을
위해서 이걸로 인증 서버를 만들어서 사용을 하는데, DB부분을
빼면(DB 자체가 동시 10K를 지원하지 않으므로...) Xeon Dual CPU에서
동시처리가 18,000개 이상이 가능했었습니다. 제가 HTTP등에 비해서
복잡한 프로토콜을 썼으므로 아마 단순한 정적 웹서버를 만든다면 훨씬 더
성능이 좋겠죠? (싱글 CPU에서는 10,000개가 좀 못되었습니다.)
또한 말씀하신 각 쓰레드(물론 이쓰레드는 StateThread를 말합니다.)의
동기화도 거의 코스트가 없이 가능합니다. 물론 제한은 있는데, Virual
Process내의 쓰레드들 끼리만 가능하기는 하죠. 대부분의 Request
-Response Loop를 통한 네트워크 어플리케이션, StateThread를 만든
사람이 말하는 Internet Application의 경우 StateThread는 훌륭한
선택의 하나라고 생각합니다.
제생각엔 어설프게 만드는 것보다는 이걸 쓰는 것이 아마 훨씬 나은 결과를
보일 것이라 생각됩니다. 비슷한 것들로 libevent나 뭐 이런 것들도 있는데
이것들은 StateThread의 저자가 말한 사용상의 불편함은 그대로 가지고
있습니다만, 쓰기에 따라서 또는 StateThread의 내부구현의 바꾸는데
이용하는 하면, 편리한 인터페이스를 유지하고 더 다양한 Event Dispatching
지원이 가능하겠지요. :-)
소스 코드와 예제를 보시면 꽤 잘만든 것이구나 하실 것입니다. 이전에 아파치
가속 프로젝트에서 쓴 것이 이것이었습니다. 아파치 그룹에서 라이센스가
다르다고 아무리 성능이 좋아도 받아주질 않았지만 말입니다. :evil:
답변이 좀 늦었습니다.[url]http://state-thread
답변이 좀 늦었습니다.
http://state-threads.sourceforge.net/
전에 조금 검토해보았는데... 상당히 흥미롭게 보았습니다.
성능도 좋다고 하네요.
우리 모두 리얼리스트가 되자. 그러나 가슴에 이룰 수 없는 꿈을 가지자
setjmp와 longjmp의 함수를 이해하고 싶습니다.
setjmp와 longjmp는 어떤 함수 입니까?
저는 FTP source를 분석하여 하나의 Module로 만들고 싶은데,
Source를 보던중 위 함수가 사용되더군요.
man page를 참조해 보면 error나 interupt를 만날때 유용하다고 쓰여 있는데, 어떻게 사용하는지 무슨 말인지 이해를 못하고 있습니다.
반갑구요, 좋은 시간들 되시길 바랍니다.
goto 문 비슷하다고 보면 됩니다.
setjmp(), longjmp() 는 소스전역에 대한 goto 문이라고 보면됩니다.
setjmp() 가 레이블이 되고.
longjmp() 가 goto 문이 되죠.
goto 과 다른 것은 setjmp() 시 현재의 스택상황을 저장하고
longjmp() 시 그때의 스택상황으로 복원하는 겁니다.
폐인, 노가다 그 끝은..?
Java나 C++의 try catch 같은 것으로 보시면 됩니다.
물론 다른 식으로 이용할 수도 있겠지만요. 그리고 위에서 누가 언급하신
state thread도 한번 참고 해 보십시오. 사용자 레벨 쓰레드라고 말하기는
좀 어렵지만 네트워크 관련이나 적어도 파일 descriptor에 대해서는
처리가 가능합니다.
state thread
단순히 호기심 때문이 아니라면 굳이 이런 라이브러리를
사용할 이유는 없어 보입니다.
CPU가 1개인 일반 PC 환경에서는 의미가 있어 보이지만,
사용의 염두에 두고 고기능성 제품을 만들고자 한다면
좋은 선택은 아닌듯 생각되는군요.
이 State Thread 라이브러리는 예전 넷스케이프에서 개발된
자체 쓰레드 라이브러리(아마도 이 당시에는 전반적으로
쓰레드를 제대로 지원하는 OS가 SUN외에는 없었고,
표준도 제대로 잡히지 않았던 때였던 걸로 기억됩니다)
를 수정해서 Diet한 것이라고 알고 있는데
표준도 아니고, 단순히 I/O에 대한 빠른 Multiplexing을 필요로 할 경우
쓰레드 문맥으로 쉽게 표현(구현?)할 수 있도록 해 주는 것 이상은 아닙니다.
다중 CPU환경에서의 Scalability를 고려하고, Inter Process간의
Synchronization을 생각하면 이득보다는 실이 많다고
생각이 듭니다.
물론 사용하는 사람에 따라 다른 결과가 나오겠지만요...^^
좋은 결과 있기 바랍니다.
고도의 추상화, 극도의 구체화, 에디슨을 그리워하다.
SMP 의 성능을 최대한 끌어 쓸 수 없다는 것은 맞습니다만, 하부의 실
SMP 의 성능을 최대한 끌어 쓸 수 없다는 것은 맞습니다만, 하부의 실질적인 I/O는 SMP 사용을 알아서 커널이 할테니까 조금은 이득이라고 생각하구요. 이걸 분배 못하는 OS도 있겠지만 다른 프로세스들도 돌고 있을테니...
그 동기화 때문에 이런 류의 쓰레드 라이브러리를 쓰기도 합니다. 일반적인 선점형 쓰레드 라이브러리는 언제 컨텍스트 스위칭이 일어날 지 모르는 상황이라 엄청난 동기화 객체가 난무하게 마련인데, 이런 라이브러리는 그야말로 io 동작 혹은 지정한 함수 외에는 스위칭이 일어나지 않는 것을 확실히 할 수 있으므로, 프로그래밍이 한결 쉬워집니다.
Synchronization을 생각하면 실보다 득이 많다고 생각이 듭니다.
Re: state thread
아마 일반적인 사용자레벨 쓰레드 라이브러리와 혼돈을 하신 것 같은데,
StateThread는 그런 문제들, 즉 다중 CPU에서의 확장문제나 이런 것들을
해결하기 위해서 나온 것입니다. C10K문제를 아마 아실텐데, 제가 고객을
위해서 이걸로 인증 서버를 만들어서 사용을 하는데, DB부분을
빼면(DB 자체가 동시 10K를 지원하지 않으므로...) Xeon Dual CPU에서
동시처리가 18,000개 이상이 가능했었습니다. 제가 HTTP등에 비해서
복잡한 프로토콜을 썼으므로 아마 단순한 정적 웹서버를 만든다면 훨씬 더
성능이 좋겠죠? (싱글 CPU에서는 10,000개가 좀 못되었습니다.)
또한 말씀하신 각 쓰레드(물론 이쓰레드는 StateThread를 말합니다.)의
동기화도 거의 코스트가 없이 가능합니다. 물론 제한은 있는데, Virual
Process내의 쓰레드들 끼리만 가능하기는 하죠. 대부분의 Request
-Response Loop를 통한 네트워크 어플리케이션, StateThread를 만든
사람이 말하는 Internet Application의 경우 StateThread는 훌륭한
선택의 하나라고 생각합니다.
제생각엔 어설프게 만드는 것보다는 이걸 쓰는 것이 아마 훨씬 나은 결과를
보일 것이라 생각됩니다. 비슷한 것들로 libevent나 뭐 이런 것들도 있는데
이것들은 StateThread의 저자가 말한 사용상의 불편함은 그대로 가지고
있습니다만, 쓰기에 따라서 또는 StateThread의 내부구현의 바꾸는데
이용하는 하면, 편리한 인터페이스를 유지하고 더 다양한 Event Dispatching
지원이 가능하겠지요. :-)
소스 코드와 예제를 보시면 꽤 잘만든 것이구나 하실 것입니다. 이전에 아파치
가속 프로젝트에서 쓴 것이 이것이었습니다. 아파치 그룹에서 라이센스가
다르다고 아무리 성능이 좋아도 받아주질 않았지만 말입니다. :evil:
댓글 달기