프로세스 간 통신의 정적 입력 액터 모델에 대해 실행 불가능한 것이 있습니까?

Question

그래서 저는 최근에 장난감 용량 밖에서 akka를 만났습니다. 정적 유형에 대한 scala의 일반적인 선호에도 불구하고 OTP가 동적 타이핑을 공유한다는 것을 알 수 없습니다. 나는 조금 뜯어 먹기 시작했고, erlang 프로세스 간 통신을 통해 HM 타입 시스템을 설명하는 this Wadler paper을 보았습니다. 즉, an answer to this question from SO은 Wadler와 Marlow가 프로세스 형식 통신으로 제공하는 스케치를 제공하지 못했음을 나타냅니다.

def receive = { 
    case "test" => log.info("received test") 
    case _ => log.info("received unknown message") 
    } 

내가 실제로 투석기 실제 타입 시스템의 이익의 큰 거래를 제공 할 수 있다는 것을 알고 있지만, 정확히 왜에 그것은 너무 어렵습니다 : 는 참고로,이 같은 코드의 대부분은 실망 정적으로 검증 된 배우 시스템을 만드시겠습니까? 타입 시스템을 사용할 때 액터 시스템 대신 Future 또는 Observable/Iteratee 라이브러리 또는 Channel- 모델링 된 IO를 쓰는 경향이 있습니까? 아니면 Wadler와 Marlow가 놓친 기술적 인 어려움이 있습니까?

Answer 1

Akka 배우 세계에 안전을 가져 오려면 몇 년 동안 논의되고 연구 된 것이 있습니다. 현재 진행중인 노력의 현시는 Akka Typed API이며 변경 될 수 있습니다.

몇 년 전 Akka 사용자 목록에 대한 흥미로운 토론 (형식없는 프로그래밍을 형식없는 프로그래밍과 어떻게 조화시킬 수 있습니까?)은 입력 된 액터에 대한 통찰력을 제공합니다. 몇 가지 발췌 전체 컨텍스트에 대한 전체 토론 here를 읽을 수 있지만 다음과 같습니다 :

---

데릭 와이어트 에서 :

당신이 겪고있는 것은 트레이드 오프입니다. 액터는 고려하지 않은 트레이드 오프를 제공합니다. 끝점 (액터)은 형식이 지정되지 않고 처리되는 메시지는 강력하게 형식화됩니다.

액터가 유형별 수신 방법으로 "기타"를 처리 할 수 ​​없도록 설정하십시오. 액터 프로그래밍을 사용하면 두 개의 끝점을 방해하지 않고 메시지 흐름에 중개자를 추가 할 수 있어야합니다. 중개자는 똑같이 일어나고있는 일 (로드 밸런서, 라우터, 로거, 캐처, 중재자, 분산 - 수집 등)에 대해 잘 모르고 있어야합니다. 또한 엔드 포인트를 방해하지 않고 클러스터 주위로 이동할 수 있어야합니다. 또한 어떤 일이 진행되고 있는지를 실제로 이해할 필요없이 Actor에서 동적 위임을 설정할 수 있습니다. 예를 들어, "주 dialect"를 사용하지만 말한 내용을 이해하지 못하면 다른 것을 위임 한 액터입니다.

이러한 기능을 모두 제거하려면 찾고있는 유형 안전 결정 성을 얻을 수 있습니다 (동일한 JVM에 머무르는 한 - 교차 JVM은 " 컴파일 시간 보증을 제거하는 질문입니다. ") ...

간단히 말해서, 완전히 새로운 기능 세트에 대한 문을 열려면 유형 안전을 포기해야합니다. 유형 안전을 잃고 싶지 않아?Endre 바르에서 문 :

---

를 닫습니다 :

문제는 시스템이 지역이 아닌 분산 계산을 위해 설계되는 유형입니다. 예를 살펴 보겠습니다.

세 가지 상태, 그것이 형 X의 메시지를 수락하고, 하나를 수신하면,이 상태 B에서는

그것을 받아 B로 천이 상태 (A)에서 A, B 및 C

• 를 갖는 배우 상상 Y는 다음 주 C에서 B
• 에 남아있는 경우 타입 X와 Y의 메시지는 X가 C에, 전환을 수신 할 때,

지금이 상태에서 시작하는 배우로 보내 타입 Z의 메시지를 수락 메시지 X. 2 개 일이 일어날 수 있습니다

• X가 전달되기 때문에 가능한 허용 유형은 {X, Y}
• X가 손실되기 때문에 허용 유형은 사람들의 {X}

교차점이다 {X}입니다.

이제

당신이 세 가지 일이 일어날 수있는 또 다른 메시지 X를 보내 상상 : 모두 X 년대 전달했다

• 를, 그래서 허용 유형은 {Z}는 X의의
• 하나 전달 된 것입니다, 다른 손실 때문에 허용 유형
• 모두 X 용의가 손실 된 {X, Y}입니다이며, 허용 유형은

위의 경우의 교집합은 공집합 {X}입니다.

그래서 X 유형의 두 가지 메시지를 보낸 액터의 로컬 유형 표현은 무엇입니까?

예를 수정하고 메시지 손실이없는 것으로 가정하고 다른 발신자의 관점을 봅시다. 이 발신자는 다른 발신자가 두 개의 X를 예제 액터에 보냈다는 것을 알고 있습니다. 어떤 메시지를 보낼 수 있습니까?

• 모두 X의 허용 유형 {Z}에서 기타 보낸 사람이 보낸 최초의 X가 아직 도착했습니다
• 이 때문에, 이미 도착했습니다 다른 보낸 사람이 보낸, 그래서 허용 유형 : 세 가지 시나리오가 있습니다 {X는 Y}
• 에는 X 년대는 아직 도착하지 않았다되며, 접수 유형은

위의 경우의 교차점이 공집합 {X}입니다.

배우에서 답장을받지 못하면 증명할 수있는 배우 유형은 대개 Nothing이거나 쓸모없는 것입니다.회신 만 액터의 유형을 전달할 수 있으며 동시 발송자가있는 경우에도 보장 할 수 없습니다.

---

박사 롤랜드 쿤에서 :

난 당신이 토론을 가져 기뻐요, 내 욕망 Akka 정적 입력의 어떤 수준을 추가 할 수는 오래된 내 프로젝트 참여. 1.x를 살펴보면 akka.actor.Channel [T]를 염두에 두었고 2.1과 2.2에는 매크로 기반 실험으로 Typed Channels가 있습니다. 후자는 사고 실험에서 코드로 실제로 넘어갔습니다. 정적 유형이 매우 동적 인 시스템과 상호 작용하는 방식에 대한 느낌을 얻기 위해 사용해 볼 수 있습니다.

입력 된 채널의 주요 단점은 부적절한 복잡성 (형식 매개 변수가 너무 많고 형식 수준 목록 및지도가 포함 된 너무 복잡한 형식)이었습니다. 우리는 점진적으로 올바른 균형을 맞출 수있는 디자인에 점차 집중하고 있습니다 만, 본질적으로 Akka 액터들로부터 sender을 제거하는 것을 의미합니다 (이는 미래의 변형에서 사물을 마무리하는 것과 관련하여 매우 환영받는 다른 이점도 있습니다). 그것의 요지는 ActorRef [T]가 받아들이는 메시지 유형 (Props [T], Actor [T] 등의 명백한 노크 - 온 효과)으로 매개 변수화하는 것입니다. 그런 다음 액터는 적절한 유형의 자체에 대한 참조를 노출 할 수 있으며, 형식 지우기를 위해 특정 메시지의 다른 액터로 보냅니다. 이것은 심지어 메시지 프로토콜, a.k.a. 세션 유형의 공식화 또는 적어도 그것의 근사화를 허용합니다.

Derek는 액터 모델이 실제로 유형에 제약을받지 않는 이점을 얻었음을 나타냅니다. 메시지 라우터는 메시지 모델을 통과하는 메시지에 대해 반드시 알아야 할 필요는 없습니다. 라우터 자체를 매개 변수화하기 위해 얼마나 잘 작동하는지는 아직까지 알 수 없지만 일반적으로 이러한 라우팅 단계는 유형 정보를 파괴합니다. 우리가 할 수있는 일은 많지 않습니다. 어떤 유형 검사가 전혀없는 것보다 나을 때 좋다고 생각하는 점은 나에게 잘 어울리는 점이다. 차이점은 개발자에게 분명히 분명하다. 우리는 잘못된 보안 감각을 피해야한다.

이렇게하면 Endre가 정적 검증에서 동시 동작에 액세스 할 수 없다는 유효한 의미를 갖게됩니다. 문제는 비 결정적인 액션이 타입 분리를 야기한다는 메시지 손실보다 훨씬 더 넓어서 타입 구조의 기하 급수적 인 폭발을 통해 멋진 정적 타입을 죽입니다. 이것은 결정적으로 타입을 사용하는 것만을 타입으로 표현할 수 있음을 의미합니다. 타입 A의 메시지를 액터로 보내면 타입 B의 메시지를 얻을 수 있습니다 (이것은 액터 리셉션 [B] A와 B는 일반적으로 "이 액터에서 허용하는 모든 명령"과 "보낼 가능성이있는 모든 응답"과 같은 합계 유형입니다. 컴파일러가 실제로 발생하는지 여부를 알 수 없으므로 액터의 질적 인 상태 변화를 모델링하는 것은 불가능합니다.

비록 약간의 빛이 있습니다. 대상의 ActorRef [C]를 포함하는 메시지 B를받은 경우 메시지 A의 효과가 발생했다는 증거가 있으므로 배우가 지금 있다고 가정 할 수 있습니다 메시지 C를 허용하는 상태입니다. 그러나 이것은 보장이 아니며, 그 동안에 배우가 추락했을 수 있습니다.

이 중 어느 것도 원격 메시징에 의존하지 않습니다. 액터를 동시성과 분배 부분으로 분리하려는 당신의 욕구는 매우 이해하기 쉽습니다. 그런 다음 동시성과 배포가 실제로 동일하다는 것을 깨닫게되었습니다. 프로세스는 실행이 공간 또는 시간으로 분리되어있는 경우 즉, 분산된다는 의미에서 동시에 실행될 수 있으며 반면에 유한 한 광속은 분산 된 프로세스를 의미합니다 정의에 의해 동시성이 될 것입니다.우리는 액터에 대한 캡슐화와 구획화를 원하며 메시지를 사용하여 통신합니다.이 모델은 두 명의 액터가 항상 서로 분리되어 동일한 JVM에서 실행되는 경우에도 배포된다는 것을 의미합니다 (대기열이 가득 차거나 실패 할 수 있음, 통신이 가능함). 신뢰성은 네트워크의 경우보다 훨씬 높지만 완전히 신뢰할 수는 없습니다. 현대 프로세서에 대해 생각해 보면, 다른 코어와 특히 소켓은 네트워크로 분리되어있어, 그랜드 아빠의 기가비트 이더넷보다 훨씬 빠릅니다.

이것은 바로 액터 모델이 현재 및 미래의 응용 프로그램에서 독립적 인 조각을 모델링하는 데 적합한 추상화라고 생각하는 이유입니다. 하드웨어 자체가 점점 더 많이 분산되고 배우가 그 본질을 파악하기 때문입니다. . 그리고 제가 위에서 논한 것처럼 정적 인 타이핑 측면에 개선의 여지가 있습니다.