FIX: Add proxy_lock_count for multiple proxy in a process

[namsic]

• jam2in/arcus-perl-client#66

• proxy_lock 파일명에 sequential index를 추가합니다.

• 하나의 프로세스에서 다수의 proxy를 생성하는 경우의 이름 충돌을 방지합니다.

[uhm0311]

질문입니다.
0으로 초기화하지 않아도 되나요?

[namsic]

예. 값을 설정하지 않으면 0 값을 가지게 됩니다.
상단의 static int azk_count도 별도로 초기화하지 않고 사용하는 것을 확인할 수 있습니다.

0으로 설정한다는 것을 보다 확실히 드러내기 위하여 = 0;을 명시할 수는 있겠습니다.

[jhpark816]

0으로 초기화해 주시죠.

[jhpark816]

아래와 같이 proxy_lock_count 값 접근 시에만 lock 잡는 코드이면 충분하지 않나요?

  char ap_lock_fname[64];

  pthread_mutex_lock(&proxy_lock_mtx);
  snprintf(ap_lock_fname, 64, ".arcus_proxy_lock.%d.%d", getpid(), ++proxy_lock_count);
  pthread_mutex_unlock(&proxy_lock_mtx);

  . . .

그리고, multi-process 환경이더라도
do_arcus_proxy_create() 호출하는 process는 parent process일 것으로 보이고,
Parent process가 single thread이면 do_arcus_proxy_create()는 순차적으로 호출될 것 같습니다.
그러면, proxy_lock_mtx도 필요 없지 않는 지 ?
어떻게 생각하나요?

[namsic]

아래와 같이 proxy_lock_count 값 접근 시에만 lock 잡는 코드이면 충분하지 않나요?

원래는 proc_mutex_create()에 실패하는 경우 proxy_lock_count를 다시 원복시키려고 했습니다.
생각해 보니 굳이 proxy_lock_count를 되돌리지 않아도 문제가 없을 듯 하여 관련 코드를 제거했는데, lock 조정하는 것을 미처 생각하지 못했습니다.

Parent process가 single thread이면 do_arcus_proxy_create()는 순차적으로 호출될 것 같습니다. 그러면, proxy_lock_mtx도 필요 없는 것이 아닌지?

process는 여러 thread를 가질 수 있으므로 전역 변수는 당연히 lock을 잡고 수정해야 한다고 막연히 생각했는데,
말씀을 듣고 보니 부모 프로세스에서 여러 스레드를 두고 각 스레드가 proxy를 생성하는 것은 일반적인 사용 패턴은 아닌 것 같습니다.

아래와 같이 사용하는 경우는 없다고 보아야 하겠지요?

1. parent process에서, threadA, threadB 생성
2. 각 thread에서 proxy 생성
   • threadA에서는 serivceA에 대한 proxy 생성
   • threadB에서는 serviceB에 대한 proxy 생성
3. 각 proxy에 대한 child process 생성

[jhpark816]

@namsic
parnet process에서 어떻게 함수를 호출할 지 모르기 때문에
lock을 두는 것은 유지하고,
locking 방식만 위의 코멘트에 제시한 방식대로 변경합시다.

[namsic]

변경했습니다.