스칼라 배우 - 최악의 연습?

StackOverflow https://stackoverflow.com/questions/1549251

  •  20-09-2019
  •  | 
  •  

문제

스칼라에서 배우를 사용하는 것에 대해 약간 불안한 느낌이 듭니다. 나는 물건을하는 방법에 대한 문서를 읽었지만 자유롭게 사용하기 위해 규칙이 필요하지 않을 것 같습니다. 나는 그것들을 잘못된 방식으로 사용하는 것이 두렵다고 생각합니다. 그리고 나는 그것을 알아 차리지 않을 것입니다.

적용하면 스칼라 배우가 가져 오는 혜택을 깨뜨릴 수있는 무언가를 생각할 수 있습니까?

도움이 되었습니까?

해결책

  • 피하다 !? 가능한 한. 너 ~ 할 것이다 잠긴 시스템을 얻으십시오!

  • 항상 액터-서브 시스템 스레드에서 메시지를 보내십시오. 이것이 일시적인 행위자를 통해 일시적인 행위자를 만드는 것을 의미한다면 Actor.actor 그런 다음 방법 :

    case ButtonClicked(src) => Actor.actor { controller ! SaveTrade(trdFld.text) }

  • 추가 "다른 메시지" 배우의 반응에 대한 핸들러. 그렇지 않으면 잘못된 배우에게 메시지를 보내고 있는지 알아내는 것은 불가능합니다.

    case other => log.warning(this + " has received unexpected message " + other

  • 사용하지 마십시오 Actor.actor 당신의 주요 배우, subsass Actor 대신에. 그 이유는 서브 클래싱에 의해서만 합리적인 것을 제공 할 수 있기 때문입니다. toString 방법. 다시 말하지만, 로그를 디버깅하는 행위자는 다음과 같은 문장으로 통나무가 흩어져 있으면 매우 어렵습니다.

    12:03 [INFO] Sending RequestTrades(2009-10-12) to scala.actors.Actor$anonfun$1

  • 시스템의 행위자를 문서화하고, 어떤 메시지를받을 것인지 명시 적으로 명시하고 정확하게 응답을 계산 해야하는 방법을 명시하십시오. 행위자를 사용하면 표준 절차 (일반적으로 방법 내에서 캡슐화 된)를 변환하여 여러 행위자의 반응에 걸쳐 논리가 퍼집니다. 좋은 문서화없이 길을 잃는 것은 쉽습니다.

  • 항상 배우 외부의 배우와 의사 소통 할 수 있는지 확인하십시오. react 상태를 찾기 위해 루프. 예를 들어, 나는 항상 MBean 다음 코드 스 니펫처럼 보입니다. 그렇지 않으면 배우가 실행 중인지, 종료되었는지, 메시지 등의 대기열이 큰지 알기가 매우 어려울 수 있습니다.

.

def reportState = {
  val _this = this
  synchronized {
    val msg = "%s Received request to report state with %d items in mailbox".format(
                   _this, mailboxSize) 
    log.info(msg)
  }
  Actor.actor { _this ! ReportState }
}

  • 배우를 함께 연결하고 사용하십시오 trapExit = true - 그렇지 않으면 그들은 조용히 실패 할 수 있음을 의미합니다. 귀하의 프로그램이 귀하가 생각하는 일을 수행하지 않으며 액터의 사서함에 메시지가 남아있을 때 메모리에서 벗어날 것입니다.

  • 배우를 사용하여 만들어야 할 디자인 설명에 관한 다른 흥미로운 선택이 강조되었다고 생각합니다. 여기 그리고 여기

다른 팁

나는 이것이 실제로 질문에 대답하지는 않는다는 것을 알고 있지만, 메시지 기반 동시성은 공유 메모리 스레드 기반 동시성보다 더 이상한 오류가 발생하기 쉬운 사실에 적어도 마음을 사로 잡아야합니다.

나는 당신이 배우 가이드 라인을 보았다고 가정합니다 스칼라로 프로그래밍, 그러나 기록을 위해 :

  • 배우는 메시지를 처리하는 동안 차단해서는 안됩니다. 차단하고 싶은 곳은 나중에 메시지를 받으려고 준비하십시오.
  • 사용 react {} 보다는 receive {} 가능할 때.
  • 메시지를 통해서만 배우와 의사 소통합니다.
  • 불변의 메시지를 선호합니다.
  • 메시지를 독립적으로 만듭니다.
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top