Your feedback wanted!

[polytypic]

I'm creating this issue as a general request for feedback and discussion.

Feel free to add comments on Picos to this issue or open a discussion.

• Questions on anything about Picos.
• Comments on how you feel about Picos in general.
  • As a potential user of concurrent programming libraries in OCaml, how do you see Picos?
  • As a potential provider of concurrent programming libraries (schedulers etc), how do you see Picos?
    • Would you make your library Picos compatible or implement it in Picos?
• Specifics in Picos that you find problematic.
• Is something missing?
• Should something be removed?
• General suggestions for improvements.

Critique is welcome, but please keep a friendly tone! 🙇

Picos is not yet considered to be final, so changes are possible — even likely.

I will especially promise to try my best to explain the rationale and ideas behind the design. Much of it might not be immediately apparent or documented.

[francoisthire]

I am reading the code, and I am wondering why is there an annotation @inline never there? What would be the issue if it was inlined? https://github.com/ocaml-multicore/picos/blob/main/lib/picos/bootstrap/picos_bootstrap.ml#L4

[francoisthire]

Another question: with a Trigger, why does an action takes two parameters instead of one? It does not sound obvious to me the kind of use-case for having two parameters, maybe performance reason to avoid allocating a tuple?

[polytypic]

why is there an annotation @inline never there? with a Trigger, why does an action takes two parameters instead of one

Yes, both of those are for low level performance reasons. Note that the core picos framework is not intended for application level programming and it is important that higher level libraries can be built on top of it without having to significantly compromise performance.

The @inline never attribute can be useful, for example, with functions that are called from branches that are unlikely taken or not performance sensitive. The awaiting () function is only called in case a programming error is detected. Having @inline never there can slightly reduce the cache footprint of the normal execution path(s).

Note that Trigger.on_signal (and Trigger.from_action) should only be called by a scheduler (or in some special cases where you essentially want to attach a callback to a computation and cannot afford to use fibers). In normal use cases a Trigger is much like a kind of single use/sticky Condition variable and you use it as a simple first order abstraction and don't attach callbacks to it (that capability is for schedulers). The use of extra arguments can avoid having to allocate a closure (or tuple) for the action. Two extra arguments has been just enough in the practical cases and uses fewer words than a closure (or tuple) would. Admittedly it is a rather low level detail.