# Threads in the same process share:
* Process instructions
* Most data
* open files (descriptors)
* signals and signal handlers
* current working directory
* User and group id
# Each thread has a unique:
* Thread ID
* set of registers, stack pointer
* stack for local variables, return addresses
* signal mask
* priority
* Return value: errn
그러니까 쓰레드는 프로세스 내에서 다른 작업을 동시에 수행하기위한 존재가 되겠죠.
필연적으로 자원을 공유할 수 밖에 없습니다.
새로 프로세스를 만드는게 정답이겠네요.-ㅅ-;
개념적으로 본다면 쓰래드는 '작은 프로세스'라는 개념입니다.
또한 프로세스 간의 데이타를 교환할 경우 shared memory나
IPC(Interprocess CAll) 같은 개념을 썼는데
쓰래드는 한 프로세스의 매모리를 공유하므로 이러한 난해한 작업도 줄어든다는 잇점이 있고.
프로세스를 fork하는 것보다 훨씬 cost가 적게 든다는 장점이 있습니다.
결론적으로 말하면 multi-threaded ftp server는 구현 가능합니다.
님의 문제는 별개의 쓰래드 간에 간섭이 일어났다고 보는데요
설계상에 분병히 오류가 있다고 보여지고요
각 쓰래드별로 논리적으로 별개의 메모리를 가지고 핸들링 했는지 검토해 보시기 바랍니다.
ftp 포트를 리스닝 하고 있다가 들어온 소켓 디스크립터를
각각 독립적인 worker thread에다가 할당해 주어야 하고요
작업이 끝났을 경우 놀고 있는 쓰래드를 어떻게 관리할 지도 생각해봐야 겠지요.
어차피 시스템 사양에 따라 동시에 돌릴 수 있는 쓰래드의 수는 제한되어 있으니까요.
이 숫자 같은것을 configuration file에 넣고 그 설정에 따라 서버가 기동되게 하는 것도 필요합니다.
POSIX 쓰레드의
POSIX 쓰레드의 개념입니다.
그러니까 쓰레드는 프로세스 내에서 다른 작업을 동시에 수행하기위한 존재가 되겠죠.
필연적으로 자원을 공유할 수 밖에 없습니다.
새로 프로세스를 만드는게 정답이겠네요.-ㅅ-;
소켓 문제는 프로세스간 통신으로 해결될 것 같네요.
설계상의 오류가 있는 것 같습니다.
개념적으로 본다면 쓰래드는 '작은 프로세스'라는 개념입니다.
또한 프로세스 간의 데이타를 교환할 경우 shared memory나
IPC(Interprocess CAll) 같은 개념을 썼는데
쓰래드는 한 프로세스의 매모리를 공유하므로 이러한 난해한 작업도 줄어든다는 잇점이 있고.
프로세스를 fork하는 것보다 훨씬 cost가 적게 든다는 장점이 있습니다.
결론적으로 말하면 multi-threaded ftp server는 구현 가능합니다.
님의 문제는 별개의 쓰래드 간에 간섭이 일어났다고 보는데요
설계상에 분병히 오류가 있다고 보여지고요
각 쓰래드별로 논리적으로 별개의 메모리를 가지고 핸들링 했는지 검토해 보시기 바랍니다.
ftp 포트를 리스닝 하고 있다가 들어온 소켓 디스크립터를
각각 독립적인 worker thread에다가 할당해 주어야 하고요
작업이 끝났을 경우 놀고 있는 쓰래드를 어떻게 관리할 지도 생각해봐야 겠지요.
어차피 시스템 사양에 따라 동시에 돌릴 수 있는 쓰래드의 수는 제한되어 있으니까요.
이 숫자 같은것을 configuration file에 넣고 그 설정에 따라 서버가 기동되게 하는 것도 필요합니다.