Re: How to blocking async future execution until future don't complete?

[Matthew Butler]

That's correct.

Process.run() returns a ProcessResult

http://api.dartlang.org/docs/continuous/dart_io/ProcessResult.html

This is basically the results of executing the process and nothing else. Just the exit code, and strings that were sent to stderr and stdout by the application.

Process.start() returns a Process object. This object is then interacted with, async, by using call backs. This allows you to interactively communicate with a process. Such as wait for an output/prompt and send back data to the process while its running. You use callbacks such as onStart, and communicate with InputStream and OutputStream which you can also use callbacks to receive/send data such as 'onData'

http://api.dartlang.org/docs/continuous/dart_io/InputStream.html#onData

Basically Process.run() is a one shot, run a command and wait for the results. Like "ls -al"

Process.start() is something you can interact with like say "telnet localhost", wait for the username prompt, then send "myUsername", wait for a password prompt and send your password... something you can interact with or call repeatedly.

This really shows the benefits and uses of the two async methods in dart. Futures are great for one-shot deals. For asyncs that are called once and only once. Callbacks are a better fit when you need to deal with the async multiple times, or are reusable.

I'm not sure what you mean by your first question, however, you can use Futures.wait() to wait for a list of futures, which will return a single Future with a List of the values.

http://api.dartlang.org/docs/continuous/dart_core/Futures.html

Hope this helps,

Matt

On Thursday, August 23, 2012 9:09:11 AM UTC-3, mezoni wrote:

Also some little question about dart:io Process.

Future<ProcessResult> Process.run(...) // Uses Fututre and is assync

Process Process.start(..)  // Don't uses Future and also is assync?

They both asynchronous?

[Olivier NOUGUIER]

Hi,
 IMHO "sleep" is not possible, in general you can do:

Futures.wait(...).then( (result){
  doWhatYoutWant();
});

The doWhatYouWant block will be called after Futures completion.

On Thu, Aug 23, 2012 at 2:59 PM, mezoni <andrew...@gmail.com> wrote:

Thanks for the clarification on the second question. Everything is simple and clear.

Future.wait(...) not block execution process.It run all futures in parallel and wait them all.

I need realy blocking mechanism. Even the most primitive like that.

while(true) {

sleep(1000);

  if(done || isTimeToBreak()) {

    break;

  }

}

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

--
"Computers are useless. They can only give you answers."
- Pablo Picasso -

[Ben Laurie]

On 23 August 2012 13:00, mezoni <andrew...@gmail.com> wrote:
> How to blocking assync process execution?
> Or by other words how to convert async to sync?

It is not possible.

> Or is there sleep() method in dart?

[Michael Hendricks]

On Thu, Aug 23, 2012 at 6:00 AM, mezoni <andrew...@gmail.com> wrote:

How to blocking assync process execution?

Or by other words how to convert async to sync?

You might be interested in issue 104 which requests an "await" keyword similar to C#.  The issue comments cover some of the ideas for making asynchronous Dart code more pleasant.

-- 

Michael

[Keith Schulze]

While its very rudimentary you could use the Timer interface from dart:io. 

For example:

Future test = ///future from somewhere

new Timer.repeating(500, (Timer t) {

   if (test.isComplete) {

      t.cancel();

   }

});

print(test.value);

[Keith Schulze]

Sorry, I meant the Timer interface from dart:isolate.

[Bob Nystrom]

On Thu, Aug 23, 2012 at 8:57 AM, Keith Schulze <keith....@gmail.com> wrote:

Sorry, I meant the Timer interface from dart:isolate.

On Friday, 24 August 2012 01:23:31 UTC+10, Keith Schulze wrote:

While its very rudimentary you could use the Timer interface from dart:io. 

For example:

Future test = ///future from somewhere

new Timer.repeating(500, (Timer t) {

   if (test.isComplete) {

      t.cancel();

   }

});

print(test.value);

That won't work, unfortunately. It will immediately throw a FutureNotCompleteException. That code will execute like so:

1. Create the future.

2. Create a new Timer, passing in the callback function. That function gets added to the list of callbacks that are waiting to be invoked on the event loop when ready.

3. Try to print test.value. Since the future hasn't completed yet, it throws.

...

4. If we hadn't thrown at some point in the future the timer fires and then the callback is invoked.

In Dart, there is no way to block to turn an asynchronous operation into a synchronous one. Like JavaScript, the language's execution model simply doesn't allow it.

Dart is built around a core event loop. Dart sits idle waiting for some internal operation to complete (like a Timer being ready, or an IO operation finishing). When that happens, it finds the callback associated with that event and invokes that Dart code. It then runs that Dart code to completion before it returns to the event loop to see if anything else is ready to run.

That means you can't block to wait for an async operation to complete. Async operations only complete when all Dart code has finished running and control has returned to the event loop.

If you sit and busy wait in your Dart code, the thing you're waiting on will never finish because it's waiting for your code to return so it can have its turn.

This definitely does make some things painful to work with in Dart. You can't encapsulate an async operation. If you do something async, then everything above you on the callstack must also be written in async style.

- bob

[Keith Schulze]

Hi Bob,

Thanks for clarifying that for me. I mocked up a quick example before posting last time that seemed to run okay. Given what you've just said, I'm not sure why it ran. So could you take a look and maybe explain it for me. I'm still coming to grips with the whole async model. Thanks

#import("dart:io");

#import("dart:isolate");

void main() {

  Completer<String> comp = new Completer<String>();

  comp.complete(costlyWork());

  Future test = comp.future;

  

  new Timer.repeating(500, (Timer t) {

    if(test.isComplete) { 

      t.cancel();

     }

    });

 print("Hello, ${test.value}");

}

/**

 * Dummy heavy function

 */

String costlyWork(){

  var sw = new Stopwatch.start();

  while (sw.elapsedInMs() < 5000){}

  return "world";

}

Cheers,

Keith

[Bob Nystrom]

On Thu, Aug 23, 2012 at 3:18 PM, Keith Schulze <keith....@gmail.com> wrote:

Hi Bob,

Thanks for clarifying that for me. I mocked up a quick example before posting last time that seemed to run okay. Given what you've just said, I'm not sure why it ran. So could you take a look and maybe explain it for me. I'm still coming to grips with the whole async model. Thanks

#import("dart:io");

#import("dart:isolate");

void main() {

  Completer<String> comp = new Completer<String>();

  comp.complete(costlyWork());

  Future test = comp.future;

  

  new Timer.repeating(500, (Timer t) {

    if(test.isComplete) { 

      t.cancel();

     }

    });

 print("Hello, ${test.value}");

}

/**

 * Dummy heavy function

 */

String costlyWork(){

  var sw = new Stopwatch.start();

  while (sw.elapsedInMs() < 5000){}

  return "world";

}

Cheers,

Keith

That doesn't do exactly what you think it does. :)

If you add a print() right after the call to completer.complete() you'll see that print() doesn't get hit until after the costlyWork has completed. So it's synchronously doing the costly work to completion before it ever even gets to your new Timer() call. In fact, if you remove all of the Timer code completely, it will still work as before:

#import("dart:io");

#import("dart:isolate");

void main() {

  Completer<String> comp = new Completer<String>();

  comp.complete(costlyWork());

  Future test = comp.future;

  print("Hello, ${test.value}");

}

/**

 * Dummy heavy function

 */

String costlyWork(){

  var sw = new Stopwatch.start();

  while (sw.elapsedInMs() < 5000){}

  return "world";

}

- bob

On Friday, 24 August 2012 07:20:09 UTC+10, Bob Nystrom wrote:

On Thu, Aug 23, 2012 at 8:57 AM, Keith Schulze <keith....@gmail.com> wrote:

Sorry, I meant the Timer interface from dart:isolate.

On Friday, 24 August 2012 01:23:31 UTC+10, Keith Schulze wrote:

While its very rudimentary you could use the Timer interface from dart:io. 

For example:

Future test = ///future from somewhere

new Timer.repeating(500, (Timer t) {

   if (test.isComplete) {

      t.cancel();

   }

});

print(test.value);

That won't work, unfortunately. It will immediately throw a FutureNotCompleteException. That code will execute like so:

1. Create the future.

2. Create a new Timer, passing in the callback function. That function gets added to the list of callbacks that are waiting to be invoked on the event loop when ready.

3. Try to print test.value. Since the future hasn't completed yet, it throws.

...

4. If we hadn't thrown at some point in the future the timer fires and then the callback is invoked.

In Dart, there is no way to block to turn an asynchronous operation into a synchronous one. Like JavaScript, the language's execution model simply doesn't allow it.

Dart is built around a core event loop. Dart sits idle waiting for some internal operation to complete (like a Timer being ready, or an IO operation finishing). When that happens, it finds the callback associated with that event and invokes that Dart code. It then runs that Dart code to completion before it returns to the event loop to see if anything else is ready to run.

That means you can't block to wait for an async operation to complete. Async operations only complete when all Dart code has finished running and control has returned to the event loop.

If you sit and busy wait in your Dart code, the thing you're waiting on will never finish because it's waiting for your code to return so it can have its turn.

This definitely does make some things painful to work with in Dart. You can't encapsulate an async operation. If you do something async, then everything above you on the callstack must also be written in async style.

- bob

[Keith Schulze]

Ha, very true! Seems I have a lot to learn.... sorry for polluting the post everyone.

Thanks,

K

[Bob Nystrom]

On Thu, Aug 23, 2012 at 3:57 PM, Keith Schulze <keith....@gmail.com> wrote:

Ha, very true! Seems I have a lot to learn.... sorry for polluting the post everyone.

No need to apologize. Posts like this are helpful for you and people who stumble onto this later. Async code in the style that JavaScript code and Dart use is really unintuitive and takes a while to wrap your head around.

Cheers!

- bob

[Eric J. Smith]

I think you nailed it with your unintuitive comment.  It definitely takes a while to get in the async mindset.  If only Dart had an await keyword to make async programming feel like traditional code. :-)

#import("dart:io");

#import("dart:isolate");

void main() {

  var result = await costlyWork();

  print("Hello, $result");

}

/**

 * Dummy heavy function

 */

Future<String> costlyWork(){

  var sw = new Stopwatch.start();

  while (sw.elapsedInMs() < 5000){}

  return "world";

}

[Ladislav Thon]

> I think you nailed it with your unintuitive comment.  It definitely takes a while to get in the async mindset.  If only Dart had an await keyword to make async programming feel like traditional code. :-)
>
> #import("dart:io");
> #import("dart:isolate");
>
> void main() {
>   var result = await costlyWork();
>   print("Hello, $result");
> }

Recently, I started to worry about this a little. There are people who actually think that this code runs synchronously! But, well, I can't think of anything better. Sometimes education is the correct solution.

LT

[Moises Belchin]

2012/8/23 mezoni <andrew...@gmail.com>

Thanks for the clarification on the second question. Everything is simple and clear.

Future.wait(...) not block execution process.It run all futures in parallel and wait them all.

I need realy blocking mechanism. Even the most primitive like that.

“Make things as simple as possible, but not simpler"

I had to change my mind many times. Always there is a way to do it async. I suggest you try to study other way to do the things via async.

Regards and good luck with your code.

 

while(true) {

sleep(1000);

  if(done || isTimeToBreak()) {

    break;

  }

}

[Eric J. Smith]

I think that is a good thing.  Obviously there are differences and developers should be aware of those differences, but the vast majority of the time await allows you to easily write code that looks like normal code and works exactly how you want it to work while still being async and providing the performance benefits of being async.

JavaScript and Dart callback hell can get really ugly really fast.  I think the await keyword alone would be a HUGE selling point for the Dart language over JavaScript.

[Bob Nystrom]

On Fri, Aug 24, 2012 at 9:07 AM, Eric J. Smith <er...@codesmithtools.com> wrote:

I think that is a good thing.  Obviously there are differences and developers should be aware of those differences, but the vast majority of the time await allows you to easily write code that looks like normal code and works exactly how you want it to work while still being async and providing the performance benefits of being async.

JavaScript and Dart callback hell can get really ugly really fast.  I think the await keyword alone would be a HUGE selling point for the Dart language over JavaScript.

I know a lot of us on the team feel the same way. async/await is definitely on our minds, but we don't have any immediate plans to add it to the language. It's the kind of feature that can be added later, so our natural inclination is to push it off to try to keep things simple and manageable for M1.

Cheers!

- bob

 

On Thursday, August 23, 2012 11:01:29 PM UTC-5, Ladislav Thon wrote:

> I think you nailed it with your unintuitive comment.  It definitely takes a while to get in the async mindset.  If only Dart had an await keyword to make async programming feel like traditional code. :-)
>
> #import("dart:io");
> #import("dart:isolate");
>
> void main() {
>   var result = await costlyWork();
>   print("Hello, $result");
> }

Recently, I started to worry about this a little. There are people who actually think that this code runs synchronously! But, well, I can't think of anything better. Sometimes education is the correct solution.

LT

--

[Ladislav Thon]

> I think that is a good thing.  Obviously there are differences and developers should be aware of those differences

Not really. There are fundamental differences in the computation model and developers _absolutely must_ know what code is sync and what is async. It wouldn't be that critical in a language without mutable state, but yeah...

But as I said, I believe that the correct solution here is proper education. Luckily, Dart isn't the first language to come with this, and AFAIK, Dart's await (in the prototype) had the same semantics as C#'s await. And I quite like that instead of an async keyword, functions in Dart still returned Future -- maybe it's a little more verbose, but I like that it's explicit and the main issue is the caller side anyway.

> but the vast majority of the time await allows you to easily write code that looks like normal code and works exactly how you want it to work while still being async and providing the performance benefits of being async.
>
> JavaScript and Dart callback hell can get really ugly really fast.  I think the await keyword alone would be a HUGE selling point for the Dart language over JavaScript.

Totally agree with this. Await is a must and I truly believe it will come.

LT

[Jeff Gardner]

It's difficult to have asyn code on the server.  Since the request coming in from the client is going to return and if your asyn requests don't finish before then what can you do. 

thanks

Jeff

[Bob Nystrom]

On Wed, Jun 19, 2013 at 8:34 PM, Jeff Gardner <jgard...@gmail.com> wrote:

It's difficult to have asyn code on the server.  Since the request coming in from the client is going to return and if your asyn requests don't finish before then what can you do. 

Dart's HTTP API is itself asynchronous. You don't have to finish responding to a request before you unwind the callstack. The HttpResponse class is an asynchronous stream that you can write to whenever you want. The response doesn't end until you explicitly call close() on it.

Cheers!

- bob

[Edouard Tavinor]

Yepp, await is a great idea. Has any progress been made here?

Ed

[Bob Nystrom]

On Mon, Sep 30, 2013 at 2:41 AM, Edouard Tavinor <edouard...@gmail.com> wrote:

Yepp, await is a great idea. Has any progress been made here?

Not yet. It's not on our radar for 1.0, so work on it has been tabled for the meantime.

Cheers!

- bob

[Jirka Daněk]

The bug tracking it is Bug #104, you can follow that.

I sort of like the Go concurrency model of being synchronous by default and adding asynchronicity when needed on the higher levels… Obviously this is not applicable for a single threaded event loop environment. But Dart does not have to be single threaded. Being able to dispense with callbacks the author of the lower level API put in when it does not make much sense in my use case would be great. Is going to be great. Eventually.

[Bob Nystrom]

On Thu, Nov 21, 2013 at 1:00 AM, Jirka Daněk <jirka...@gmail.com> wrote:

I sort of like the Go concurrency model of being synchronous by default and adding asynchronicity when needed on the higher levels…

I like Go's concurrency model too.

 

Obviously this is not applicable for a single threaded event loop environment. But Dart does not have to be single threaded.

We are primarily a client-focused language (i.e. in the browser). That means compiling to JavaScript, which is single-threaded. It's a really unfortunate limitation, but it's a necessary one to not break the web.

 

Cheers!

- bob

[Lasse R.H. Nielsen]

Being single-threaded is its own reward in many other ways. The most important one is to not have to worry about all the synchronization issues that comes with being multi-threaded: Race conditions, memory barriers/memory model, mutexes and the deadlocks they allow.

I wasn't there when it was decided, but I don't think compatibility with Javascript is the only reason for Dart to be single-threaded. It really is *that* much simpler.

/L

-- 

Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Günter Zöchbauer]

Usually the developer has to create threads, there is usually only one initially.

With one thread you can only utilize one CPU core and that's pretty lame in times of 8 core cpus with hyperthreading in common desktops and notebooks.

[Bob Nystrom]

On Thu, Nov 21, 2013 at 11:47 PM, Lasse R.H. Nielsen <l...@google.com> wrote:

Being single-threaded is its own reward in many other ways. The most important one is to not have to worry about all the synchronization issues that comes with being multi-threaded: Race conditions, memory barriers/memory model, mutexes and the deadlocks they allow.

You can all of those benefits without giving up user-level concurrency by doing green threads/fibers, which is what Go does by default. True multi-threading is a pain. But having to manually use callbacks/futures and CPS transform all of your code is a real nightmare.

- bob

[dangli...@gmail.com]

I have proposal of how to implement in Dart (and not only in Dart).
I was starting work on that but I was stopping for some reason.
Who I am? Why I must do this work?
Enough about me.
I read your posts and make sure that you do not have the good ideas.
Or to be more precisely you not have ready solutions that can come-to life.
I have (project) and this is not my research even I not look into source code of the existent implementations but my thoughts are the same with this difference that it is not my idea (I am not first).

I have no doubt that you implement this feature.
But your thoughts are so far from understanding the essence of the problem is that sometimes I just wonder.

I did not want in any way to hurt anybody and I do not want to downplay your existing merits.
But this issue (as I understand) you not ready to solve in appropriate way.

Believe me it's much easier than you think.
It are so much easier that it reminds the following.

- You begin working on problem
- You know the problem (or you know that you not know the problem) and you know that you not know the solution
- You begin research that also include discovering existent solutions
- You begin implement some ideas
- You ideas work but so good as expected
- You continue research (discovering) and more deeply plunge into problem of finding the best solution
- You found the next solution
- You implement (at least partially) this and it not work as expected (remember at least that was before "lib_v2_io" in Dart))
- You start finding the next solution
- And finally you come to the conclusion that, in the end, even though it was not invented by you (because you are not the head of gold), but it is a good decision and it will work.

Unfortunately, here I have not heard anything new that would could move this process forward.
I am deeply sorry about that.

P.S.
And I'm sorry if I offended anyone. I am not a resident of the English-speaking world.

P.S.P.S.
The solution is very easy and can be easily implemented in Dart.
It really easy to implement in any language not only in Dart, easy to understand, and hard for implement by hand coding.
But with special algorithms (generators, analyzers, eliminators, transformers) it can be implemented, in the end.

And hope it (feature) in some day, in some form or another, will appear in Dart.

[dangli...@gmail.com]

I just want to say that as the first form it can be implemented in Dart language similar to "dart2js" or even "java2dart" tools.
Very similar to "dart2dart" which transform the human readable code into the some implementation.
That is, human readable source code with "async/await" into the implementation of the asynchronous tail calls into source code in existent version of Dart language.
Pros, very fastest.
Cons, output code like after the "dart2js" are not easy to understand from the first view.
But this is not cons because you have only three choice.
1. Human readable and very slow implementation like when the computer do this work for you as code transformation into "then().then().then()"
2. Something different to #1 option but with utilizing current "dart:async" library
3. Something different to #1, #2 options that may work without (and with) "dart:async". Fast but not using continuations in that way which currently used in Dart.
I am about "then()", "catchError()", "whenComplete()".
These operations not required but any "awaitable" can be transformed into "Future" and vice versa with special wrappers if required.

Belive me, that even in Dart (Javascript) missing "goto" statement (the main essence of generators ) this not means that it  cannot be used and applied, and, at the end, eliminated into another structural statements.

[Gen]

What is the easy solution ?

PS
Instead of being sorry, do not write about people.
Instead write about what is wrong about Dart and how things would be better.

[Gen]

For my use of Dart, the Javascript output is not important.
If it was, I would rather use Typescript or ES 6 directly.
Instead I wish Dart to be usable and better than ES 6; whatever it takes.

[mythz]

Go still requires synchronization as goroutines on closures can reference the same shared variables.

I'm with Crockford on this: http://www.yuiblog.com/blog/2010/08/30/yui-theater-douglas-crockford-crockford-on-javascript-scene-6-loopage-52-min/

multi-threading shouldn't be in general purpose/application-level programming languages, either be blocking and enable synchronous code or non-blocking and be single-threaded and dispense with all multi-threading issues, having both is the worst of both worlds. 

IMO Dart's choice of single-threaded with concurrency via message-passing to isolates is the best choice, even without the constraints of single-threaded JS.

On a side-note, having done some C#/F# async, async/await is by far the best/productive async programming model I've used. The source code requires a lot less artificial complexity/machinery, which as a result ends up being much more intuitive and readable. Despite the compiler magic everything works well in practice, e.g. even exception handling works as expected.

- Demis

[dangli...@gmail.com]

>> What is the easy solution ?

Easy solution to get it ready are to begin work in this direction.
Look at this simple code.

try {
  var hello = await new Future(() => hello);
  print(hello);
} catch(e) {
  print(e);
} finally {
  print("finally");
}

How this can be compiled to effective code?
You have any ideas? I have.
But for me interesting to know which ideas has Dart Team.
And for me very interesting which solution they implement.
Not important which line of thought from me. It is important to what solution will present Dart Team.
It is important to understand that asynchronous operations is a very simple thing.
But I spent a lot of time to understand it.
If a person feels it, he will understand that it's easy.
But a lot of work needs to be done.
Because the way to solve the problem affects many other related issues.
It required to solve all other related issues.

These issues consist from these applications.
- Generating special kind of asynchronous functions.
Easy problem that just requires to write backend generator of such function.
- Finding in asynchronous function special operators (in our case "await")
Easy problem that just requires to write visitor pattern in frontend.
- Finding blocks that contains these expressions.
This includes aslo "pre" and "post" conditional or "initial" parts of some statements like "if/then" or "loop" statements).
These parts may not affect on inner blocks but affect on outer block.
Example.

while(true) {
  if(awiat something) {
  }
}

"While" is async because inner "if" is async. "if" is async because conditional expression is async. But "if" body are sync.

"If" in this case becomes to.
var temp = await something.
if(temp) {
}

"If" already not async but the "while" still async.
And "temp" requires tail call.

This problem not hard. Also implemented as visitor.

- The next task to rewrite this code using "goto" statemnts. At this phase allowed to write unreachable code with indirect realated "goto's". Later this code will be transformed into normal code.

// Some labels skipped
async() {
  var state = 1;
  void moveNext() {
   if(state == 0) {
       goto L_END;
    }

    if(state == 1) {
       goto L0;
    }

    if(state == 2) {
       goto L1;
    }

   L0:
   while(true) {     
      var awaiter = something.WeWaitYouCallThisMethodWhenCompleted(moveNext);
      var state = 2;
      return;
      L1:
      var temp = awaiter.getValue;
      if(temp) {
      }
   }
  }
}

This code cannot be compiled because not possible "goto" into middle of body of "while" statement.
But later this code will be transformed into appropriate code.

I not want explain all nuances how this can implemented because this is possible work and even I (not programmer) can implement this behavior.
That means that all known statements including exception handling statements and, of course, the exception handling behavior can be rewritten in this manner.
This just required a some time for non experts. No more and no less.

This work has a finite time for their completion (into some an acceptable point) but this time may include requirement to spend it on education, research, coding, testing, re-analyzing problems, refactoring and, of course, it requres time for generating ideas.

No one will bring you something on a white platter and says, "Take it, it's free".

All of the above work should be performed by someone.

P.S.

This sample not include for simplicity many other items that need to be taken into account when implementing because this is just example.
Not ask me how and why. Please educate yourself by themselves.

[Demis Bellot]

AFAIC isolates being heavy now is an implementation detail which I'm sure will improve once it's been given the required level of attention. What's important now was getting the message-passing concurrency semantics right. But yeah they're fairly unusable now as they max out at 100 isolates, which meant I had to go shopping elsewhere when trying to compile jaded dart views at runtime.

It's fine for low-level languages and OS's to have threads, just IMO not high-level general purpose programming languages as multi-threading continues to be a major source of bugs and requires so much added complexity and cognitive overhead to your environment/code-base. Your code can no longer works the way it reads, as you now have to build up the context  in your head of imagining hundreds of threads racing around and running the same code at any one time, and you can no longer rely that your code will run to completion as it can be swapped out in the middle of it and context switched into another thread.

IMO a major part of node.js's popularity on the server is due to its simplicity in being able to create high-performance non-blocking servers with single-threaded JS whilst only needing to know a minimal/small API surface. The one thing that it is missing is a good story for asynchrony given how it's an essential part of a non-blocking platform. There's a good chance Erlang has had it right all along, as IMO the mainstream high-level languages like Java/C# got it wrong by subjecting us to multi-threading issues.

On Sat, Nov 23, 2013 at 3:51 AM, Ladislav Thon <lad...@gmail.com> wrote:

Since this keeps popping up in my inbox...

I'm with Crockford on this: http://www.yuiblog.com/blog/2010/08/30/yui-theater-douglas-crockford-crockford-on-javascript-scene-6-loopage-52-min/

multi-threading shouldn't be in general purpose/application-level programming languages, either be blocking and enable synchronous code or non-blocking and be single-threaded and dispense with all multi-threading issues, having both is the worst of both worlds.

On the other hand, multithreading is THE low-level solution that is employed by OSes. Which makes it THE building block that you can build higher-level solutions on top of. That is -- you can implement actors on top of threads, you can implement STM on top of threads, you can implement data-flow concurrency on top of threads, etc.

 

IMO Dart's choice of single-threaded with concurrency via message-passing to isolates is the best choice, even without the constraints of single-threaded JS.

Yeah, that would be true if isolates were lightweight as they were promised to be. They are not, which makes them the worst of both worlds -- you can't use them as actors, and you can't use them as a primitive to build other concurrency abstractions.

TBH, the more I think about it, the more I'm sure that Erlang did asynchrony/concurrency right 30 years ago, and since then, we are doing it all wrong. More at http://joearms.github.io/2013/04/02/Red-and-Green-Callbacks.html

LT

[Christopher Thomas]

This library can help https://pub.dartlang.org/packages/heavylist

    HeavyList<File> abc = new HeavyList<File>([new File(), new File(), ]);

    abc.loop(new Duration(seconds: 1), (List<File> origin) {

    print(origin);

    }, (File item, Function resume) {

      //simulating an asynchronous call

      print(item);

      //move to next item

      resume();

    });

On Thursday, 23 August 2012 07:36:00 UTC-5, Matthew Butler wrote:

That's correct.

Process.run() returns a ProcessResult

http://api.dartlang.org/docs/continuous/dart_io/ProcessResult.html

This is basically the results of executing the process and nothing else. Just the exit code, and strings that were sent to stderr and stdout by the application.

Process.start() returns a Process object. This object is then interacted with, async, by using call backs. This allows you to interactively communicate with a process. Such as wait for an output/prompt and send back data to the process while its running. You use callbacks such as onStart, and communicate with InputStream and OutputStream which you can also use callbacks to receive/send data such as 'onData'

http://api.dartlang.org/docs/continuous/dart_io/InputStream.html#onData

Basically Process.run() is a one shot, run a command and wait for the results. Like "ls -al"

Process.start() is something you can interact with like say "telnet localhost", wait for the username prompt, then send "myUsername", wait for a password prompt and send your password... something you can interact with or call repeatedly.

This really shows the benefits and uses of the two async methods in dart. Futures are great for one-shot deals. For asyncs that are called once and only once. Callbacks are a better fit when you need to deal with the async multiple times, or are reusable.

I'm not sure what you mean by your first question, however, you can use Futures.wait() to wait for a list of futures, which will return a single Future with a List of the values.

http://api.dartlang.org/docs/continuous/dart_core/Futures.html

Hope this helps,

Matt

On Thursday, August 23, 2012 9:09:11 AM UTC-3, mezoni wrote:

Also some little question about dart:io Process.

Future<ProcessResult> Process.run(...) // Uses Fututre and is assync

Process Process.start(..)  // Don't uses Future and also is assync?

They both asynchronous?