KC Sivaramakrishnan

Any thoughts on this @ctk21 @Engil?

@dbuenzli (On my phone; please excuse the lack of code formatting) I view Domain.join to be analogous to awaiting on a promise. The normal or the exceptional result from the...

> In fact I would rather argue that it is a bad idea, as lwt messy design w.r.t. exceptions and cancellation has shown us. Lwt's problem with exceptions is that...

Currently, the situation is that | Thread | Uncaught exception handler | |----|----| | Main (1st) thread of the program | `Printexc` module's uncaught exception handler | | Threads created...

> Optionally remove the API Domain.at_each_spawn, which is a bad API for other reasons discussed somewhere else. I am failing at finding the reasoning as the discussion is spread across...

> but I am not sure (in the litteral, non-British sense) that it is a realistic constraint for users. (My own library-writing experience is that I do not want to...

> What goes right? I don't have examples where this is useful API after the first spawn. Right. If that is the case, should we consider raising an exception if...

> How about simply moving the calls to flush each std formatter to the init functions of the standard formatter DLS keys (and so avoid creating the buffers on domain...

> arrays: document that operations on arrays are not linearizable For non-float-arrays, individual reads and writes respect the memory model; memory safety is preserved and there are no crashes with...

> Tearing only happens for float arrays on architectures where the word size and double size is mistaken, isn't it? Yes, for all operations except blit. For float arrays, we...