현재 버전

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 짚어보고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다. 물론 그것을 동기/비동기를 구분하는 기준으로 삼는 것 자체가 무조건 틀린것이다라고 생각하지는 않습니다. 중요한건 일관성이니까요. 예를 다시 보겠습니다. 


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, 초고속io의 대명사인 Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


다시 말하지만 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 "일관적인" 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하여지기에는 무리가 있다고 생각합니다.

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 아~ 구분점이 명확치 않다 라고 규정하고 감만 잡는것도 좋습니다.  ^^

감사합니다.





수정 이력

2019-09-20 22:08:45 에 아래 내용에서 변경 됨 #12

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다. 물론 그것을 동기/비동기를 구분하는 기준으로 삼는 것 자체가 무조건 틀린것이다라고 생각하지는 않습니다. 중요한건 일관성이니까요. 예를 다시 보겠습니다. 


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, 초고속io의 대명사인 Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


다시 말하지만 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 "일관적인" 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하여지기에는 무리가 있다고 생각합니다.

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 아~ 구분점이 명확치 않다 라고 규정하고 감만 잡는것도 좋습니다.  ^^

감사합니다.




2019-09-20 22:08:18 에 아래 내용에서 변경 됨 #11

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다. 물론 그것을 동기/비동기를 구분하는 기준으로 삼는 것 자체가 무조건 틀린것이다라고 생각하지는 않습니다. 중요한건 일관성이니까요. 예를 다시 보겠습니다. 


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, 초고속io의 대명사인 Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 "일관적인" 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기 지기에는 무리가 있다고 생각합니다.

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 아~ 구분점이 명확치 않다 라고 규정하고 감만 잡는것도 좋습니다.  ^^

감사합니다.




2019-09-20 10:07:21 에 아래 내용에서 변경 됨 #10

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다. 물론 그것을 동기/비동기를 구분하는 기준으로 삼는 것 자체가 무조건 틀린것이다라고 생각하지는 않습니다. 중요한건 일관성이니까요. 예를 다시 보겠습니다. 


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 "일관적인" 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기 지기에는 무리가 있다고 생각합니다.

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 아~ 구분점이 명확치 않다 라고 규정하고 감만 잡는것도 좋습니다.  ^^

감사합니다.




2019-09-20 09:58:16 에 아래 내용에서 변경 됨 #9

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다. 물론 그것을 동기/비동기를 구분하는 기준으로 삼는 것 자체가 무조건 틀린것이다라고 생각하지는 않습니다. 중요한건 일관성이니까요. 예를 다시 보겠습니다. 


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 "일관적인" 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기 지기에는 무리가 있다고 생각합니다.

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 아 구분점이 명확치 않ㅢㆍ라고 규정하고 감만 잡아도 됩니다. ^^

감사합니다.




2019-09-20 09:57:28 에 아래 내용에서 변경 됨 #8

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다. 물론 그것을 동기/비동기를 구분하는 기준으로 삼는 것 자체가 무조건 틀린것이다라고 생각하지는 않습니다. 중요한건 일관성이니까요. 예를 다시 보겠습니다. 


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 "일관적인" 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기 지기에는 무리가 있다고 생각합니다.

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 

감사합니다.




2019-09-20 09:34:24 에 아래 내용에서 변경 됨 #7

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다. 물론 그것을 동기/비동기를 구분하는 기준으로 삼는 것 자체가 무조건 틀린것이다라고 생각하지는 않습니다. 중요한건 일관성이니까요. 예를 다시 보겠습니다. 


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 "일관적인" 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기에는 무리가 있다고 생각합니다. (글쓴님께서 이게 답같다라고 대중들에게 말하려는건 아닌거 같습니다만) 

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 

감사합니다.




2019-09-20 09:28:52 에 아래 내용에서 변경 됨 #6

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다. 물론 그것을 동기/비동기를 구분하는 기준으로 삼는 것 자체가 무조건 틀린것이다라고 생각하지는 않습니다. 중요한건 일관성이니까요. 예를 다시 보겠습니다. 


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 "일관적인" 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기에는 무리가 있다고 생각합니다. (글쓴님께서 이게 답이다라고 대중들에게 말하려는게 아닌거 같습니다만..나는 이렇게 생각한다 정도) 

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 

감사합니다.




2019-09-20 09:27:41 에 아래 내용에서 변경 됨 #5

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다. 물론 그것을 동기/비동기를 구분하는 기준으로 삼는 것 자체가 무조건 틀린것이다라고 생각하지는 않습니다. 중요한건 일관성이니까요. 예를 다시 보겠습니다. 


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 "일관적인" 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기에는 무리가 있다고 생각합니다. (글쓴님께서 이게 답이다라고 대중들에게 말하려는게 아닌거 같습니다만..나는 이렇게 생각한다 정도) 

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 

감사합니다. ^^








2019-09-20 09:27:31 에 아래 내용에서 변경 됨 #4

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 존재를 강조하셨습니다. 

근데 제 생각으론 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다.예를 다시 보겠습니다.


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 일관적인 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기에는 무리가 있다고 생각합니다. (글쓴님께서 이게 답이다라고 대중들에게 말하려는게 아닌거 같습니다만..나는 이렇게 생각한다 정도) 

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 

감사합니다. ^^








2019-09-20 09:26:14 에 아래 내용에서 변경 됨 #3

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

위 댓글에서는 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 행위를 강조하셨습니다. 

근데 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다.예를 다시 보겠습니다.


1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 일관적인 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기에는 무리가 있다고 생각합니다. (글쓴님께서 이게 답이다라고 대중들에게 말하려는게 아닌거 같습니다만..나는 이렇게 생각한다 정도) 

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 

감사합니다. ^^








2019-09-20 09:25:48 에 아래 내용에서 변경 됨 #2

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에 대해 오류도 지적하고 제 생각도 말해 보겠습니다.

이 댓글에서 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 행위를 강조하셨습니다. 근데 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다.

예를 다시 보겠습니다.

1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 일관적인 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기에는 무리가 있다고 생각합니다. (글쓴님께서 이게 답이다라고 대중들에게 말하려는게 아닌거 같습니다만..나는 이렇게 생각한다 정도) 

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 

감사합니다. ^^








2019-09-20 09:25:18 에 아래 내용에서 변경 됨 #1

@devEvan

글 잘 읽었습니다.
댓글로 써 주신 글에서는 본문 보다 더 문제가 있어 보여서, 설명 해 봅니다.
(먼저 본인이 그렇게 생각하고 싶다. 라고 하는 걸 부정하는 건 아닙니다. 중요한건 일관성이니까요)

이 댓글에서 동기/비동기의 주요 요소로  "주 프로세스의 역할" 을 강조하셨습니다. 
그리고 콜백/이벤트 핸들러의 행위를 강조하셨습니다. 근데 이벤트를 받아서 처리하든, 짬짬히 기다리든... 이런 것은 하나의 소프트웨어 "트릭" 에 불과하다고 생각됩니다.

예를 다시 보겠습니다.

1)

패스

2)

Proactor 패턴의 주요관삼사는 " 이벤트 핸들링"이 아닙니다.  그것은 단지 하나의 "트릭"에 지나지 않으며 
해야 할 일(Job)에 대한 제어권을 수동적으로 받아드리냐, 능동적으로 처리하냐의 차이입니다.
예를들어 우체국에 짐을 마구 던저버리는 행위는 proactor,  우체국에서 자리가 났다고 알려주면 그 때서야 짐을 들고 가는 것을 reactor라고 볼 수 있는데, Windows IOCP 등 여러 비동기 입출력 Implementation에서, Write를 던져 놓고,  "주 프로세스" 는 GetQueuedCompletionStatus 를 통해 블록되어 기다립니다. 
우체국에 짐을 던져놨는데, 우체국이 다 보냈어요~~ 라고 알림을 주면 그때 "주 프로세스" 는 GetQueuedCompletionStatus 에서 리턴되어, 잘 보내졌는지 or 먼가를 받았는지 확인하고, 받은 결과에 대해서는 Worker 쓰레드들에게 넘기고 다시 "주 프로세스" 는 대기하게 됩니다. 

자 여기서 그럼 "주 프로세스" 가 기다리니깐 동기 라고 한다면 , 그냥 쓰레드 하나 더 만들어서 거기서 
"GetQueuedCompletionStatus 를 기다리면" 비동기가 될 까요?? 그죠 이건 그냥 레이어링을 얼만큼 하느냐에 따라서 달라지는 문제라고 볼 수 있습니다.
 

3)

Future 패턴도 마찬가지 입니다. isDone을 쓰던, 별도의 Executor를 쓰던 이것은 그냥 트릭에 불과 합니다.
큰 그림에서는 결국 다른 쓰레드or 프로세스 or 네트워크 넘어 누군가에서 처리하고 있는 "비동기" 상태로 볼 수 있기 때문입니다. 만약 isDone이 주 프로세스가 짬짬히 확인을 하는 거라서 동기라면 
쓰레드 하나 더 만들어서 그 녀석(a) 이 짬짬히 확인하게 만들고,  또 다른 쓰레드(b)에게 이벤트 핸들러를 만들어서 a에 등록시켜 놓으면 "동기"가 아닌걸까요?? 


결론적으로 그런 명제로  동기/비동기를 판단을 하는게 "틀렸다"라고 말하는건 아닙니다만.
(왜냐면 자신만의 일관적인 시각이 있으면, 개별 기술을 받아드리고 판단하는데 명쾌해지니까) 
누구에게나 동기/비동기는 이렇게 구분한다라고 말하기에는 무리가 있다고 생각합니다. (글쓴님께서 이게 답이다라고 대중들에게 말하려는게 아닌거 같습니다만..나는 이렇게 생각한다 정도) 

이 글을 읽는 분들도 여러 사람들의 생각을 종합해서 본인만의 일관적인 구분점을 갖게 되길 바랍니다. 

감사합니다. ^^