I made an example of promises implementation and usage for asking credentials by dialog. Promises allows to run some task asynchronously without locking and get notification when task completed/failed. It is useful for asking user to enter some information, alert dialogs, file download/upload requests and much more.
Maybe some GCC 2 adapted promises version can be included in Haiku source and used for various dialogs, package download and other actions that take time.
Hey X512,
I’ve recently been trying to add a promise-style kernel API to the OS I work on, and have been discussing some of the implementation details on the cap-talk google group. I am mostly discussing the underlying mechanism rather than how it looks from an application program. I hadn’t thought that far ahead, but there are some C++ promise implementations, such as Kenton Varda’s KV.
I’m aware not everyone knows the history of promises, so just a little glossary: I mention CapTP in the OP, this is the underlying mechanism for remote promises in E, the language from which JavaScript inherited them. The intention is to comprehend how promises stretch across a kernel boundary - say, messages contain references to the results of messages not yet received.
I would like to hear your thoughts, but yes, I generally think that non-blocking kernel interfaces are the way to go, and that promises (and other actor-derived concurrency models) are the best API choice (rather than anything CSP based, which generally ignore physics, latency, and unreliability).
By lock I mean thread locking. It is bad in many situations, it break window repainting and stop message handling. Logical lock of user interface can be done without thread locking.