Port the email portal to libdex #1855
Conversation
|
One design I think about when using futures/message-passing both is to treat the service as an actor. Then if the actor only handles a single message at a time, you don't have to deal with locking. If you have a situation where you need to have both concurrently processed messages and exclusively processed messages, we can create an arbitor that only allows one side to happen at a time (either concurrent messages - or - a single exclusive message). This is something I still want to add in Libdex to make this easier. Think of it as a message-base reader writer lock. |
Every AppInfo kind multiplies the number of tests. Let's run the tests with the two which will give us the biggest coverage by default. By setting `XDP_TEST_RUN_LONG`, all tests run with all AppInfo kinds. In CI, we run the tests 3 times (test in the build dir, installed tests, dist). Let's run "main" tests with XDP_TEST_RUN_LONG=1 to get the full coverage while keeping the other tests short.
We dispatch invocations in threads, including the authorize-method which creates the app info for a connection. A call to xdp_app_info_registry_ensure_for_invocation_sync however is only locking the hashtable when reading or writing to it; this means that the sequence of lookup, create new, insert is racy, and another thread can create and insert a new app info between our lookup and insert. So far this has not been a problem because there was nothing hanging off the app info and equality checks went via the app id. This will change, so we really have to make sure the whole lookup, create, insert sequence is atomic. We could just hold the global lock for it, but it would mean any other method invocation, even from other connection, will block until the app info has been created. Creating it requires a roundtrip through the dbus broker. So this takes another approach and uses a lock per connection.
|
This grew quite a bit. Always hard to not give in the urge to refactor everything. There are still a few problems, but this has portals using requests and sessions, and it all works. I will probably start pulling out stuff from here and create new PRs from it. |
2 participants
Just an experiment for now.
There are currently two main pain points:
g-authorize-methodmechanism is currently blocking the main thread when ran in a fiber. This should use async, but also needs locking across suspension points.The request/session thing could be solved by making it async, because they are local to a portal which will always either use threads or use fibers, but never both.
The async lock thing is a bit more trick /cc @chergert.