future

Advantages of actors over futures

一笑奈何 提交于 2019-12-04 03:56:57
I currently program in Futures, and I'm rather curious about actors. I'd like to hear from an experienced voice: What are the advantages of actors over futures? When should I use one instead of other? As far as I've read, actors hold state and futures doesn't, is this the only difference? So if I have true immutability I shouldn't care about actors? Please enlighten me :-) One important difference is that actors typically have internal state, and therefore theoretically, they are not composable; see this and this blog post for having some issues elaborated. However, in practice, they usually

Android: get result from callback (networking KOUSH ION)

烂漫一生 提交于 2019-12-04 03:52:24
For my app I need to contact our API from our server which returns some JSON. While downloading the JSON, it should display a progressbar. I figured I should use Android's AsyncTask to handle the GUI while doing network operations, so I wrote the following within my Activity : class DownloadManager extends AsyncTask<String, Void, Boolean> { @Override protected void onPreExecute() { super.onPreExecute(); mLoadingSpinner.setVisibility(View.VISIBLE); } @Override protected Boolean doInBackground(String... params) { String id = params[0]; downloadUtility.getId(id); return true; } @Override

Flutter: shared preferences

倾然丶 夕夏残阳落幕 提交于 2019-12-04 03:33:36
I have this function: Future<String> load(SharedPreferences prefs, String fileName) async { prefs = await SharedPreferences.getInstance(); String jsonString = prefs.getString(fileName) ?? ""; if (jsonString.isNotEmpty) { return jsonString; }else{ return ... } } What should I return in the else case? I tried with "" but it doesn't work. The answer is "it depends". Namely, it depends on what exactly you are doing with the result of this function, and what a good empty default value means in that context. Assuming you're decoding the returned JSON string into a Map<String, dynamic> , then a good

Doctest not recognizing __future__.division

夙愿已清 提交于 2019-12-04 03:28:28
I have the following doctest written x.doctest : This is something: >>> x = 3 + 4 foo bar something else: >>> from __future__ import division >>> y = 15 >>> z = int('24') >>> m = z / y >>> print (m) 1.6 But when I ran python -m doctest x.doctest on python 2.7.11, the doctest didn't recognize from __future__ import division : ********************************************************************** File "x.doctest", line 11, in x.doctest Failed example: print (m) Expected: 1.6 Got: 1 ********************************************************************** 1 items had failures: 1 of 6 in x.doctest **

spray Marshaller for futures not in implicit scope after upgrading to spray 1.2

醉酒当歌 提交于 2019-12-04 02:57:05
After updating to spray 1.2 I got a problem regarding my JSON-Marshallers that worked perfectly with 1.1. Doing the following inside a HttpService trait TestHttpService extends HttpService with SprayJsonSupport with DefaultJsonProtocol{ self : ActorLogging => case class Test(hallo: String, test: String) implicit val storyJsonFormat = jsonFormat2(Test.apply) def test(implicit m : Marshaller[Future[Test]]) = 17 def hallo = test } leads to the following error: could not find implicit value for parameter marshaller: spray.httpx.marshalling.Marshaller[scala.concurrent.Future[amanuensis.story.Story]

About Future.firstCompletedOf and Garbage Collect mechanism

落爺英雄遲暮 提交于 2019-12-04 02:35:01
I've encountered this problem in my real-life project and proved by my testing code and profiler. Instead of pasting "tl;dr" code, I'm showing you a picture and then describe it. Simply put, I'm using Future.firstCompletedOf to get a result from 2 Future s, both of which have no shared things and don't care about each other. Even though, which is the question I want to address, the Garbage Collector cannot recycle the first Result object until both of the Future s finished . So I'm really curious about the mechanism behind this. Could someone explain it from a lower level, or provide some hint

What does Future.cancel() do if not interrupting?

好久不见. 提交于 2019-12-03 22:54:29
From java docs on Future.cancel() boolean cancel(boolean mayInterruptIfRunning) Attempts to cancel execution of this task. This attempt will fail if the task has already completed, has already been cancelled, or could not be cancelled for some other reason. If successful, and this task has not started when cancel is called, this task should never run. If the task has already started, then the mayInterruptIfRunning parameter determines whether the thread executing this task should be interrupted in an attempt to stop the task. My question is what does cancel do if mayInterruptIfRunning is false

java Future 接口介绍

蹲街弑〆低调 提交于 2019-12-03 18:38:12
在Java中,如果需要设定代码执行的最长时间,即超时,可以用Java线程池ExecutorService类配合Future接口来实现。 Future接口是Java标准API的一部分,在java.util.concurrent包中。Future接口是Java线程Future模式的实现,可以来进行异步计算。 Future模式可以这样来描述:我有一个任务,提交给了Future,Future替我完成这个任务。期间我自己可以去做任何想做的事情。一段时间之后,我就便可以从Future那儿取出结果。就相当于下了一张订货单,一段时间后可以拿着提订单来提货,这期间可以干别的任何事情。其中Future 接口就是订货单,真正处理订单的是Executor类,它根据Future接口的要求来生产产品。 Future接口提供方法来检测任务是否被执行完,等待任务执行完获得结果,也可以设置任务执行的超时时间。这个设置超时的方法就是实现Java程序执行超时的关键。 Future接口是一个泛型接口,严格的格式应该是Future<V>,其中V代表了Future执行的任务返回值的类型。 Future接口的方法介绍如下: boolean cancel (boolean mayInterruptIfRunning) 取消任务的执行。参数指定是否立即中断任务执行,或者等等任务结束 boolean isCancelled ()

Multi thread: std::shared_future(2)

允我心安 提交于 2019-12-03 18:37:26
在之前我们了解到std::future,但是通过class std::future获得的结果只能get()一次,第二次调用通常会抛出一个std::future_error。 但是当多个其他线程想处理另外一个线程的结果的时候 ,也就是需要多次get(),基于这个目的C++ standard library提供了 std::shared_future,于是我们就可以多次调用get(),拿到相同的结果,或者抛出(throw)同一个异常. std::shared_future相对于std::future来说只是少了一个share()操作.别的操作基本上是与 std::future一致的. 此外还有以下几点不同: 1, std::future是不能被拷贝的(但是需要注意的是std::fututre和std::shared_future一样都是支持move的). 2, std::shared_future可以多次调用get(). 3, std::future可以通过std::future::shared()获得一个std::shared_future(当然这会导致std::future无效). 我们来看一个例子吧: #include <iostream> #include <future> #include <thread> #include <exception> #include

Futures in Haskell

左心房为你撑大大i 提交于 2019-12-03 17:38:55
问题 Does Haskell have an equivalent of Alice's ability to bind a variable to a future? val a = spawn foo; where foo is some function. I know Haskell supports channels and threads; I'm hoping for syntax as natural as Alice's to bind a value to a future and spawn a thread to calculate it without having to deal with the details. 回答1: You can use par from Control.Parallel as in a `par` f a b c where a = foo This is a hint to the runtime that a could be evaluated in another thread. 回答2: Funny, I was