> ## Content Index
> Fetch the complete content index at: https://blogs.remobjects.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Concurrency in Chrome 'Oxygène'
- URL: https://blogs.remobjects.com/2007/12/04/concurrency-in-chrome-oxygne/
- Published: 2007-12-04T11:58:16.000Z
- Updated: 2018-08-22T06:17:48.000Z
- Author: marc hoffman
- Tags: #Import 2026-08-17 20:17

As you probably know, while ‘Joyride’ is the current version of Chrome, and we plan to have many significant updates to it over the next half year, we’re also already busy planning and implementing cool stuff for ‘Oxygène’, our next major release planned for late 2008.

Among many other cool language features we have in the works (some of which we might start talking about in a short while), we sat down last week to finish our planning of one big area – Parallelism.

What we’re planning is really a set of independent features that will work together to bring unprecedented capabilities to multi-threaded development, allowing you to build applications that can leverage increasing core counts with more ease than any other mainstream language around.

Of course we have always had support for async methods and locking in the Chrome language from v1.0, but that has really only been the beginning. One of the coolest things we have planned for ‘Oxygène’ is native language support for **futures**.

A “future”, for those unfamiliar with the term, is basically a promise to provide a value at a later time. For example, imagine you have a calculation that’s split in two parts. Each part is independent, but takes a long time to compute. traditionally, you would write this sequentially, such as

**var** part1: Int32 := 1+2; \*// lets assume 1+2 is hard to calculate, here ;)\* **var** part2: Int32 := 3+4; **result** := part1+part2;

Of course *part1* takes a long time to calculate, and while that is happening, your second cpu core sits idly by. Now, what if we could make a small change to this (note that this syntax is not set in stone yet):

**var** part1: **future** Int32 := 1+2; **var** part2: Int32 := 3+4; **result** := part1+part2;

Now, *part1* is no longer an *Int32*, it is a “**future** *Int32*“. What this means, it represents the value we expect for *part1*, but that value has not been fully calculated at the time the first statement executes. In fact. the first statement will execute in just about no time, and the main thread of your application will continue to calculate *part2*.

While *part2* is being calculated, another thread (and hopefully another CPU) will get busy calculating *part1*, in the background.

Note that in our last statement, we can refer to *part1*, as if it were a plain *Int32* (not a future). What’s happening behind the scenes here? Simple: if our future has already been calculated in the background, we’re simply grabbing the result and using it as part of the expression. If calculation is still in progress (maybe *part2* was a bit faster), the expression will Wait for *part1* to be completed.

The above example is a bit contrived of course – after all, a simple addition will execute in no time. But imagine *part1* and *part2* being two halves of a quick sort operation. Or calculations over two sides of a binary tree.

Futures (and Oxygène’s other parallelism features that we will talk about another day) will make it easy to parallelize your application, while keeping your algorithms natural and intuitive, and without having to arbitrarily rearrange your code just based on what thread you want it to run on.

Stay tuned for more peeks ahead at ‘Oxygène’ soon, or grab our Future Subscription (pun not intended) to try Oxygène now, first hand!