동기식 스칼라 별도 스레드가없는 미래

기능의 일부로 HTTP 요청을하는 라이브러리를 구축하고 있습니다. 여러 환경에서 작동하도록하려면 배포 할 때 Futures를 사용하거나 사용하지 않고 작업 할 수 있어야합니다.동기식 스칼라 별도 스레드가없는 미래

비동기 HTTP 구현을 사용하는지 여부에 따라 유형이 Future 인 라이브러리 인스턴스 또는 유형이 Id 인 인스턴스를 만들 수 있도록 라이브러리 매개 변수의 응답 유형을 지정하는 것이 하나의 옵션입니다. (Id은 정체성 모나드 일 수 있습니다. 사용자에게 일관된 인터페이스를 제공하기에 충분합니다.)

저는이 방법으로 시작했지만 복잡해졌습니다. 내가 정말로하고 싶은 것은 미래의 모든 유형을 미래의 복싱 동기식 반응을 필요에 따라 사용하는 것입니다. 그러나 Futures를 사용하면 항상 threadpool이 필요하다는 것을 이해합니다. 예 : AppEngine (필수 환경).

현재 스레드에서 실행될 값에서 미래를 작성하여 스레드를 생성 할 수없는 환경에서 문제를 일으키지 않는 방법이 있습니까?

(PS 추가 요구 사항으로, 나는 scala.concurrent에서 사용할 수있는 기능 제한 할 수있는 다시 스칼라 v2.9.1에 대한 라이브러리를 구축 교차 할 수 있어야합니다) 당신이하고자 이해하는 바로는

출처

2013-08-01 adamnfish

'미래를 만들 수있는 방법이 있습니까? 현재 쓰레드에서 실행될 것입니다.'왜 미래를 사용합니까? ' – Jatin

제가 설명했듯이, 구현 전반에 걸쳐 일관된 반환 유형을 만들기 위해 – adamnfish

나는이 질문을 이해하지 못해 죄송합니다. 이미 결과의 최종 가치가 있고 미래 래퍼가 필요하다면 '약속'을 사용하는 것이 어떻습니까? – Jatin

을 무언가를 실행 한 다음 결과를 Future으로 바꿉니다. 이 경우, 당신은 항상

val p = Promise[Int] 
p success 42 
val f = p.future

Promise는 따라서 지금 42

약속 잘 here 설명 최종 값을 포함하는 future 래퍼를 사용할 수 있습니다.

출처

2013-08-01 12:46:18 Jatin

아, 물론 고마워요! 환상적인 링크. 여기서 문제는 ExecutionContxt (암시 적으로 또는 다른 방법으로)를 제공해야한다는 것입니다. 제공된 ExecutionContext가 실제로이 Promise 접근 방식과 함께 사용되지만 실제로는이 옵션이 Java에서 확인 된 예외처럼 끝나고, 컨텍스트가 미래를 소비하는 응용 프로그램을 통해 모든 방식으로 포함되어야한다는 점은 분명하지 않습니다. – adamnfish

또한 Promise 객체에는이 작업을 좀 더 간결하게 처리 할 수있는 메서드 인 Promise.successful (42) .future'가 포함되어 있습니다. – adamnfish

@adamnfish 아니요 위 코드에서 ExecutionContext가 필요하지 않습니다. 우리는 미래에 어떤 것을 제출하지 않을 것입니다. 나는 네가 그걸로 착각했다고 생각해. 단지'import scala.concurrent._'만으로 충분할 것입니다. 또한 대답을 받아들이면 대답을 받아주세요 :) – Jatin

미래형의 Scalaz 버전에서 look을 가져갑니다. fork 또는 apply이 호출되지 않고 + 모든 ExecutionContext 가져 오기를 완전히 제거하지 않는 한 현재 스레드가 실행하는 Trampoline 메커니즘을 기반으로합니다.)

출처

2013-08-01 13:26:18 4lex1v

매우 흥미로운 접근 방식, 대단히 감사합니다. 차라리 scalaz를 포함하지 않아도됩니다. 특히 최신 버전이 2.9.1까지 내장되어 있지 않기 때문에 특히 그렇습니다.하지만 ExecutionContext 가져 오기를 사용하지 않으면 매우 편리 할 것입니다. – adamnfish

동기식 스칼라 별도 스레드가없는 미래

답변

관련 문제