만약 게임을 예로 들어서
Drawing을 해주는 프로세스를 두고, 거기에 fork를 써서 Image Loading을 하는 Child 프로세스를 둬서
Child Process에서 Image Loading이 끝나면 Drawing Process에게 그걸 전달해야 하는데
만약 Pipe를 이용하면 Image가 용량이 크니깐 전달하는데에 그만큼 속도에 loss가 많을텐데
그렇다면 공유메모리를 써야하는건가??
만약 게임을 예로 들어서
Drawing을 해주는 프로세스를 두고, 거기에 fork를 써서 Image Loading을 하는 Child 프로세스를 둬서
Child Process에서 Image Loading이 끝나면 Drawing Process에게 그걸 전달해야 하는데
만약 Pipe를 이용하면 Image가 용량이 크니깐 전달하는데에 그만큼 속도에 loss가 많을텐데
그렇다면 공유메모리를 써야하는건가??
그래서 thread 씀
가장 쉬운 것은 아무래도 DB ?
아니면 미들웨어 두거나 복잡한 공유 메모리 관계를 항상 머리 속에 넣어두고 있어야 하지 않을까 ?
IPC 보세유~
물론 쓰레드가 합당한 선택이쥬. 가끔 프로세스 써야 할 경우도 있음 ( 죽을꺼면 혼자 뒈져랏~! )
Inter process communication
https://www.joinc.co.kr/w/Site/system_programing/Book_LSP/ch08_IPC
ㄳㄳ
shared memory 도 좋고 memory mapped file 도 좋고~ tcp / udp 써도 되긴 함. ( UDP 는 packet loss 없기 위해서 아주 경제적인 poller 가 필요할듯 )
원격 시스템끼리로 분할할 일이 있을땐 아무래도 TCP 가 유연. 것도 요즘은 http 베이스로 많이 하지만.
( 80포트가 프리~ 해서 )
GRPC 도 편하고
셰어드 메모리 말고 tcp udp같은 경우는 결국 그 통신으로 데이터를 넘길때 걸리는 부하를 생각했을때 안좋은 방법이지 않음?
응 근데 공유하는 정보도 확장성이 더 필요한 경우도 있잖.
고전적으론 성능필요하면 거의 무조건 shared memory 였지만, 성능을 극악 수준까지 뽑을거면 process 분할로는 좀 한계가 있구...
그럴꺼면 thread 쓰는게 맞지. 성능보단 안정성과 확장성을 생각할때 커넥션이 필요한 것.
분리를 기본 가정하잖아.
ㅇㅋㅇㅋ
근데 스레드로만 작업하면 싱글코어만 쓰니깐 느리잖아
쓰레드 생성할때 코어 지정할수 있고, 지정안하면 노는 코어 순으로 할당됨요
일단 shared memory를 써야할 것 같긴 하네
그렇구나 ㄳㄳ