Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Equinox/Futures"

(New page: ==Futures== With Equinox version 3.5M5, a new plugin has been introduced '''org.eclipse.equinox.concurrent'''. Futures are a way to provide support for easier handling of concurrency an...)
 
(Introduction)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
==Futures==
+
==Introduction==
  
With Equinox version 3.5M5, a new plugin has been introduced '''org.eclipse.equinox.concurrent'''.   
+
With Equinox Galileo M5, a new bundle has been introduced '''org.eclipse.equinox.concurrent'''.   
 
Futures are a way to provide support for easier handling of concurrency and synchronization within multi-threaded and/or distributed applications.  See [http://en.wikipedia.org/wiki/Futures_and_promises Wikipedia article] on Futures for some technical background information.
 
Futures are a way to provide support for easier handling of concurrency and synchronization within multi-threaded and/or distributed applications.  See [http://en.wikipedia.org/wiki/Futures_and_promises Wikipedia article] on Futures for some technical background information.
  
==Futures in Equinox Concurrent Bundle==
+
==Contents of Equinox Concurrent Bundle==
  
 
<xxx todo>
 
<xxx todo>

Latest revision as of 12:06, 29 January 2009

Introduction

With Equinox Galileo M5, a new bundle has been introduced org.eclipse.equinox.concurrent. Futures are a way to provide support for easier handling of concurrency and synchronization within multi-threaded and/or distributed applications. See Wikipedia article on Futures for some technical background information.

Contents of Equinox Concurrent Bundle

<xxx todo>

Examples of Using Futures

Here is an API that would normally return an Integer as the result of some synchronous computation

// foo() may be a long-running operation, and if so will block in order to 
// synchronously return the result
Integer result = foo();

With futures, foo() could instead return an IFuture, and thereby guarantee that foo() would not block indefinitely.

// foo will return the future immediately and operation will complete
// asynchronously
IFuture future = foo();
// do other things while operation is completed asynchronously
...
Integer result = (Integer) future.get();

Back to the top