당연한 얘기지만 이런 종류의 문제는 "프로그램을 잘못짰다고 결과가 잘못 나온다는" 보장이 없습니다. 매뉴얼에 "이런 거 보장 안되니 절대로 하지마라"라고 적혀있는데 해봤더니 되는 케이스도 얼마든지 가능하다는 거죠. (물론 그렇다고 되는 줄 알고 쓰다가는 마지막 순간 고객 앞에서 뻑납니다.)
그러니까 이런 문제는 매뉴얼을 확인해서 되는지 안되는지 확실히 하고 넘어가야지 "되나 안되나 해보자"는 매우 위험합니다.
mysql api 내부 구조를 모르기 때문에 상상을 해보자면...
아마도 api 내부에 네트워크 통신을 위해 소켓이 하나 열려 있을텐데요.
소켓의 경우 fork 를 하게 되면, 같은 소켓을 두개의 프로세스가 공유하게 됩니다. (완전히 새로운 소켓이 생성 복사 되는게 아니에요)
그래서 두 프로세스중에 하나에서 소켓을 close하면 다른 프로세스의 소켓도 close 됩니다.
또한 소켓에 데이터가 수신되면, 두 프로세스 모두에 수신 이벤트가 발생합니다. (이런 특징을 이용해 pre-fork 방식의 네트워크 서버 개발이 가능하죠. 또한 이런 특징때문에 "thundering herd problem"이라는 것도 발생합니다.)
두 프로세스에서 수신된 데이터를 서로 읽으려고 하다가 데이터가 꼬이게 될 것 같네요.
해보기 어려문 문제도 아니고 fork해서 쿼리가
해보기 어려문 문제도 아니고 fork해서 쿼리가 실행되는지 확인만 해보면 되는걸 질문하는 이유는 뭔가요?
시도해보고 해결하기 어려울 때 질문을 하시면 답변 다시는 분들이 더 친절하게 답변해 드릴겁니다.
음 제 생각은 좀 다른데요
이런 문제는 "fork해서 쿼리가 실행되는지" 확인해 본다고 끝나는 문제가 아닙니다.
당연한 얘기지만 이런 종류의 문제는 "프로그램을 잘못짰다고 결과가 잘못 나온다는" 보장이 없습니다. 매뉴얼에 "이런 거 보장 안되니 절대로 하지마라"라고 적혀있는데 해봤더니 되는 케이스도 얼마든지 가능하다는 거죠. (물론 그렇다고 되는 줄 알고 쓰다가는 마지막 순간 고객 앞에서 뻑납니다.)
그러니까 이런 문제는 매뉴얼을 확인해서 되는지 안되는지 확실히 하고 넘어가야지 "되나 안되나 해보자"는 매우 위험합니다.
참나.
익명이면 비평해도 되는거죠?
ㅡㅡ mysql 메뉴얼에도 안나와있는 부분이여서 주관적인 자문을 얻자는 건데 뭐가 마음에 안들어서 그러세요?
욕만 안하셨지 상대 기분 해치는 겁니다. 아님 그 방식으로 계속 코딩하는 코더가 혼자 되시지 왜 다른사람까지 끌어들여?
방법이 있긴할텐데 안쓰는게 좋지 않나요?
해보지 않아서 질문에 대한 답은 잘 모르겠지만..
관리 측면에서나 소스코드 이해면으로 볼 때 fork로 생성된 프로세스 새로 맺고 쓰게 하는게 좋지 않을까 싶습니다.
mysql api 내부 구조를 모르기 때문에 상상을
mysql api 내부 구조를 모르기 때문에 상상을 해보자면...
아마도 api 내부에 네트워크 통신을 위해 소켓이 하나 열려 있을텐데요.
소켓의 경우 fork 를 하게 되면, 같은 소켓을 두개의 프로세스가 공유하게 됩니다. (완전히 새로운 소켓이 생성 복사 되는게 아니에요)
그래서 두 프로세스중에 하나에서 소켓을 close하면 다른 프로세스의 소켓도 close 됩니다.
또한 소켓에 데이터가 수신되면, 두 프로세스 모두에 수신 이벤트가 발생합니다. (이런 특징을 이용해 pre-fork 방식의 네트워크 서버 개발이 가능하죠. 또한 이런 특징때문에 "thundering herd problem"이라는 것도 발생합니다.)
두 프로세스에서 수신된 데이터를 서로 읽으려고 하다가 데이터가 꼬이게 될 것 같네요.
댓글 달기