Hello
When spawning more threads the rm-session from the env needs to be upgraded in various places. This can occur when spawning new threads and even in thread.start().
Thus one needs a way to make the rm-session in env upgradeable from the outside.
A simple way to fix would be to define a class Upgradeable_rm_session : public Rm_session { void upgrade(const char *); };
And make some private inheritance into protected inheritance i.e. Rpc_client into template <typename RPC_INTERFACE> struct Rpc_client : *protected* Capability<RPC_INTERFACE>, RPC_INTERFACE ...
Is there a better and more non-invasive way to do this?
If not - would a patch implementing this be accepted?
An alternative would be to expose the capability in env in addition to the session, but I think that is even more ugly.
- Taru Karttunen
Hi Taru,
When spawning more threads the rm-session from the env needs to be upgraded in various places. This can occur when spawning new threads and even in thread.start().
Thus one needs a way to make the rm-session in env upgradeable from the outside.
there is already a bit of support for such upgrades in place. Please have a look at 'base/include/base/platform_env.h'. The class behind 'env()->rm_session()' is actually an 'Expanding_rm_session_client', which is meant to transparently upgrade the session quota as needed. Right now, the implementation covers only the 'attach' function though. For accommodating your concern, we should cover all functions that implicitly consume session quota. In your actual case, this would be 'add_client'.
A simple way to fix would be to define a class Upgradeable_rm_session : public Rm_session { void upgrade(const char *); };
The 'Platform_env::Expanding_rm_session' class looks actually quite similar. Could you have look to see how it fits your needs?
And make some private inheritance into protected inheritance i.e. Rpc_client into template <typename RPC_INTERFACE> struct Rpc_client : *protected* Capability<RPC_INTERFACE>, RPC_INTERFACE ...
Oh, you have just turned a public inheritance into a protected one. ;-) If a 'struct' inherits a base class with no 'private/protected/public' keyword, 'public' is default.
Cheers Norman
On Sun, 16 Sep 2012 12:36:48 +0200, Norman Feske <norman.feske@...1...> wrote:
there is already a bit of support for such upgrades in place. Please have a look at 'base/include/base/platform_env.h'. The class behind 'env()->rm_session()' is actually an 'Expanding_rm_session_client', which is meant to transparently upgrade the session quota as needed. Right now, the implementation covers only the 'attach' function though. For accommodating your concern, we should cover all functions that implicitly consume session quota. In your actual case, this would be 'add_client'.
Thanks. I was aware of the Expanding_*_client classes but I was mistaken in the belief that the thread creation used rm in some implicit way instead of going through that session. My mistake.
I'll write and submit the following patches:
1) expand Expanding_rm_session_client to handle the necessary functions 2) create Expanding_cpu_session_client and the assorted fixes (I have this code already and just need to polish it).
ps. Thanks for the patience to help with this.
- Taru Karttunen
Hi Taru,
I'll write and submit the following patches:
- expand Expanding_rm_session_client to handle the necessary functions
- create Expanding_cpu_session_client and the assorted fixes (I have
this code already and just need to polish it).
that sounds good. :-)
Btw, I think that the 'Expanding_*' classes are not really elegant right now. There is quite a bit of code duplication. Adding the case for CPU sessions will further add repetitions.
Maybe it would be beneficial to separate the retry logic (the do loop for executing a RPC function, upgrading the session if the function fails in a particular way, retry after upgrade) from the actual RPC function call? I haven't had a good idea how to do that exactly but my basic approach would be to implement the do loop in a generic way that takes the code for the RPC function call as functor argument. What do you think? Would you like to give it a try?
ps. Thanks for the patience to help with this.
You are very welcome.
Cheers Norman
-
Norman Feske -
Taru Karttunen