Home

Welcome to the COOL wiki!

COOL stands for COmmon Object Library. It started as a private project to collect commonly used idioms and pieces of code that I frequently had to write over and over again (such as IP address manipulation in cool::net namespace) or things that I found inadequate in the standard library (such as future/promise versus vow/aim from cool::basis). Soon, however, the focus of the library shifted to the support of asynchronous concepts which we as a company started to embrace as an alternative approach to the multi-threaded programming. Thus namespaces cool::gcd::async and cool::gcd::task were born, with the gcd part reflecting the fact that our initial approach was to abstract the Apple's Grand Central Station (GCD) concepts and their implementation of libdispatch.

With the intensified use of cool::gcd::task::runner, and later cool::gcd::task::task concepts we were improving their implementation to the point where they culminated in the COOL version 1.0. I feel that the development of 1.0 has reached the point where it is necessary to rethink both the concept and the implementation, and come out with something more flexible both in terms of use as well as in terms of the underlying implementation.

COOL Version 2.0

The main aim of version 2.0 is to address the deficiencies in the current asynchronous programming concepts provided by version 1.0, as follows:

• while version 1.0 enables control objects to offer access to their data via a single runner, thus eliminating need for multi-threading safety, it provides no means for enforcing such single-runner access. The 2.0 will try to address this problem by providing advanced operations for task composition, which will enable control classes to factory data manipulation tasks and hide the direct manipulation methods as private.
• version 1.0 is still pretty much lambda focused and, with the exception of recently added task::then_add method, provides no support for task composition. One of the 2.0 goals is to provide develop ruls for composing tasks into complex tasks and the implementaton of these rules that does not depend on the underlying infrastructure.
• version 1.0 heavily relies on, and almost directly reflects, the underlying libdispatch library which makes it almost unusable on non-unix-like operating systems where libdispatch port is very limited (MS Windows, for instance) and entirely unusable on operating systems where libdispatch is not available. The 2.0 will detach its concepts from the actual mechanics provided by the environment, which should make it more suitable for use with mechanisms other than libdispatch, such as Windows thread pool and their completion ports or Boost.Asio library.