Core building blocks -- computation vs trigger

[kayceesrk]

I'm trying to get to the core building blocks of picos, and teasing out the fundamental primitives from the ones that are necessary to get around the idiosyncrasies of the programming language and the compiler. My aim is to formalise the core of picos, and formally specify (and potentially automatically verify) the contracts between picos, picos-compatible schedulers and concurrency libraries implementated on top of picos.

From first look, trigger and computation both look awfully similar. Both have an "unresolved" and "resolved" states, allow users to move them from "unresolved" to "resolved" states and allow users to block wait (await) on them for the states to move from "unresolved" to "resolved" states. Computation is more expressive in that it allows triggers to be attached and detached to it.

Is Computation the core primitive with which Trigger can be implemented? Why have both?

[c-cube]

I'm not the author of picos, but in my understanding a `Computation.t` is like a regular promise. It represents something that's running, and has the moral equivalent of 3 states (running/done/canceled with exception). A trigger is more like a single-use callback in lwt (you need one trigger per `Lwt.on_termination`, more or less) that is as lightweight as possible. Unlike the callback, you can detach it if you don't need it anymore, and it's thread safe. You can attach a trigger to a computation but you can't attach a computation to another computation. So I'd compare computation to `'a Lwt.t`, and triggers to reified callbacks in Lwt (which you might want to use instead of adding more promises and rely on `>>=`, for lower level control). They're distinct because trigger will hopefully use only 2 small initial allocations, and consume 2 words only once signaled.

[kayceesrk]

Thanks. I see the difference in performance, but is there something more? If I ignore performance for now, would we be able to implement a Trigger using Computation with the expected semantics? If I were implementing an MVar using Picos, it is not clear when I would use a Trigger. Would it be cases where a computation would fit, but I want better performance? What I am trying to answer is what the fundamental abstractions are. Is Trigger fundamental?

[c-cube]

As far as I understand it, yes, trigger is fundamental and that's why it lives in the core module :-). For a MVar (a thread-safe box with 0 or 1 element, correct?) you would probably use some sort of synchronization primitive and use a trigger in the cases where you need to `await` (eg when `put`-ing an element into a currently-full MVar). Each caller gets its own trigger.

[kayceesrk]

If I ignore performance for now, would we be able to implement a Trigger using Computation with the expected semantics?

If this were true, Trigger is not fundamental, isn't it, despite where it lives? :-) Perhaps the right way to think about Trigger is that there is 1 trigger per synchronization, and there is one computation per fiber? For the latter, it is also unclear why fiber and computation aren't the same thing if there's always a 1-to-1 relationship between them.

Are there simple code examples that show the use of both schedulers and concurrency libraries implemented on top of Picos. The existing examples look complex (I assume for performance reasons).

[c-cube]

If I ignore performance for now, would we be able to implement a Trigger using Computation with the expected semantics?

I don't think you can because of the lack of attach-ing a computation to another computation, but I could be wrong. Triggers are the only mechanism for "subscribing" to something else and computations can't do that except by spawning a whole new fiber and awaiting from it (which itself might be actually done by creating a trigger and awaiting it under the hood).

I don't know of simple examples, sorry :-(. Old versions of miou, and moonpool, both use picos, and there's the sample schedulers in picos itself? But nothing super simple that I know of.

Again take what I say with a grain of salt, I'm only a user :)