Picos — Interoperable effects based concurrency


Picos is a systems programming interface between effects based schedulers and concurrent abstractions. Picos is designed to enable an ecosystem of interoperable elements of effects based cooperative concurrent programming models such as

If you are the author of an application level concurrent programming library or framework, then Picos should not fundamentally be competing with your work. However, Picos and libraries built on top of Picos probably do have overlap with your work and making your work Picos compatible may offer benefits:

Of course, interoperability does have some costs. It takes time to understand Picos and it takes time to implement Picos compatibility. Implementing your programming model elements in terms of the Picos interface may not always give ideal results. To address concerns such as those, a conscious effort has been made to keep Picos as minimal and unopinionated as possible.


Picos is essentially an interface between schedulers and concurrent abstractions. Two phrases, Picos compatible and Implemented in Picos, are used to describe the opposing sides of this contract.

Picos compatible

The idea is that schedulers provide their own handlers for the Picos effects. By handling the Picos effects a scheduler allows any libraries built on top of the Picos interface to be used with the scheduler. Such a scheduler is then said to be Picos compatible.

Implemented in Picos

A scheduler is just one element of a concurrent programming model. Separately from making a scheduler Picos compatible, one may choose to implement other elements of the programming model, e.g. a particular approach to structuring concurrency or a particular collection of communication and synchronization primitives, in terms of the Picos interface. Such scheduler agnostic elements can then be used on any Picos compatible scheduler and are said to be Implemented in Picos.

Design goals and principles

The core of Picos is designed and developed with various goals and principles in mind.

The documentation of the concepts includes design rationale for some of the specific ideas behind their detailed design.

Constraints Liberate, Liberties Constrain

Picos aims to be unopinionated and flexible enough to allow higher level libraries to provide many different kinds of concurrent programming models. While it is impossible to give a complete list of what Picos does not dictate, it is perhaps illuminating to explicitly mention some of those:

Let's build an incredible ecosystem of interoperable concurrent programming libraries and frameworks!


The Picos package is divided into multiple libraries.


The only essential part of the package is the core interface.

Everything else is entirely opt-in and you are free to mix-and-match with any other Picos compatible schedulers and libraries implemented in Picos or develop your own.

Sample schedulers

These are minimalistic, but fully-functioning, schedulers provided as samples.

You may find these useful for both understanding the core Picos interface and for testing your own libraries implemented in Picos.

Scheduler agnostic libraries

These are examples of libraries implemented in Picos.

These libraries are both meant to serve as examples of what can be done and to also provide practical means for programming with fibers. Hopefully there will be many more libraries implemented in Picos like these providing different approaches, patterns, and idioms for structuring concurrent programs.

The IO libraries in this package are built only on top of the standard libraries distributed with OCaml and are hopefully useful for building simple applications. Bindings to asynchronous system IO libraries are outside the scope of this package.

Auxiliary libraries

These have no dependency to the core Picos interface and are used in the implementation of the other libraries.

Some of these libraries might be moved to other packages in the future.


Many operation in the Picos libraries use non-blocking algorithms. Unless explicitly specified otherwise,