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.
NetFS package have a similar window, which can shake if you supply wrong password. I personally find that really annoying.
Credentials dialog is just example. There are a lot of cases of time consuming operations where locking is not desired.
Maybe new network kit may be designed on top of promises.
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 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).
I’m sure I don’t understand the half of it, but:
Isn’t login a situation where you would want to lock? You don’t want a non-authenticated user to have access to anything, right?
With a download, you don’t want to do anything to what’s being downloaded until it’s done…
What’s the best example you can come up with where you would replace an existing approach with one based on promises and async calls?
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.