I confess, i haven’t quite finished Day 2’s exercises, but i was anxious to get on and try some of the concurrency stuff. We discovered a couple of interesting things by playing around with it.
Waiting for asynchronous processes
If you start an asynchronous message but don’t add a ‘wait’, the process stays on hold until another Io process starts up. For example:
Io> slower := Object clone Io> faster := Object clone Io> slower start := method(wait(2); writeln("slowly ", Date now)) Io> faster start := method(wait(1); writeln("quickly ", Date now))
I’ve added timestamps to the example because it helps to see what is happening.
slower @@start; faster @@start ==> nil Io> Date now ==> 2011-06-26 12:33:30 BST Io> wait(3) quickly 2011-06-26 12:33:34 BST slowly 2011-06-26 12:33:35 BST ==> nil
I started both slower and faster asynchronously but didn’t wait for them to finish. I checked the current date and time for reference. Then I did a wait(3). At that point Io was in control again and could run the asynchronous processes. The timestamp shows that they didn’t run until the wait had begun.
I wonder, is there a way of detecting whether there are asynchronous processes still waiting to be run?
Actors do one thing at a time
Although you can run start on the objects slower and faster together in parallel, you can’t run two processes on the same object asynchronously. See what happens if we try:
Io> slower @@start; slower @@start; wait(5) slowly 2011-06-26 12:35:12 BST slowly 2011-06-26 12:35:14 BST ==> nil
I kind of expected those to come out at the same time, but no, it waits for the method to finish before running it again. I checked and the same thing is true with two different methods. It seems that an object does not run two methods simultaneously.
This is because the object has become an actor, and an actor manages its own resources. I suspect this is probably part of Io’s strategy for avoiding race conditions.
The concept of futures excited me. It conjured an impression that you’d be able to calculate multiple versions of possible futures … but unfortunately it’s not that exciting.
It seems that a future result is one that may not yet be known. But it doesn’t hold up your program while waiting for the answer. You can store the future answer and move on. Only when you actually try to use it will your program block until it’s available.
Calculating futures seems to follow the same restrictions as the other asynchronous actor processes, in that one object can only do one thing at a time. But two objects can calculate future results concurrently.
Ahhh, we didn’t get that far! I hope i’ll be able to do a bit before the skype call today! :)