Hello!
Genode Thread class already have infrastructure for implementing the green tasks: alloc_secondary_stack() which used i.e. in dde_linux to emulate the Linux kernel behavior. These secondary stacks have fixed maximal size and live one below another, so they can overlap each other. It is possible to create different Dataspace lists for each green stack and then switch them. Right now Genode hasn't the method for switching several DSs at once, so each DS in that list should be switched individually which would be too expensive.
The question is: even having that method, can we still consider our tasks "green"? Or such complexity is no better than the ordinal thread complexity?
Thanks!
Hello Igor,
On 01/21/2016 09:55 AM, Igor wrote:
Hello!
Genode Thread class already have infrastructure for implementing the green tasks: alloc_secondary_stack() which used i.e. in dde_linux to emulate the Linux kernel behavior.
Yes, that is correct.
These secondary stacks have fixed maximal size and live one below another, so they can overlap each other.
That is a false assumption. You can define the stack size (second argument of 'alloc_secondary_stack'), and there is always room in between the different stacks so that a stack overflow should lead to a page-fault. Where does your assumption come from?
It is possible to create different Dataspace lists for each green stack and then switch them. Right now Genode hasn't the method for switching several DSs at once, so each DS in that list should be switched individually which would be too expensive.
I do not know what you mean with dataspace switching. With regard to thread stacks, it is the stack pointer (a designated register), which is changed, nothing is changed with regard to the address space layout. In general, all threads within one component share the same view with regard to the memory layout. Therefore, I'm not sure what you mean with "dataspace switching"?
Best regards Stefan
The question is: even having that method, can we still consider our tasks "green"? Or such complexity is no better than the ordinal thread complexity?
Thanks!
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Stefan!
27.01.2016, 10:35, "Stefan Kalkowski" <stefan.kalkowski@...1...>:
Hello Igor,
On 01/21/2016 09:55 AM, Igor wrote:
Hello!
Genode Thread class already have infrastructure for implementing the green tasks: alloc_secondary_stack() which used i.e. in dde_linux to emulate the Linux kernel behavior.
Yes, that is correct.
These secondary stacks have fixed maximal size and live one below another, so they can overlap each other.
That is a false assumption. You can define the stack size (second argument of 'alloc_secondary_stack'), and there is always room in between the different stacks so that a stack overflow should lead to a page-fault. Where does your assumption come from?
It is possible to create different Dataspace lists for each green stack and then switch them. Right now Genode hasn't the method for switching several DSs at once, so each DS in that list should be switched individually which would be too expensive.
I do not know what you mean with dataspace switching. With regard to thread stacks, it is the stack pointer (a designated register), which is changed, nothing is changed with regard to the address space layout. In general, all threads within one component share the same view with regard to the memory layout. Therefore, I'm not sure what you mean with "dataspace switching"?
Indeed there are guard pages between secondary stacks. But what happens when "top" stack reaches the guard page of "bottom" stack? I mean, what should I do in the page fault handler? As far as I understand, I should somehow preserve the first page (and eventually another ones) of "bottom" stack. In general, it requires stack pages switching, right?
Thank you for answer. You know, Genode is perfect environment for languages like Go and Erlang. So for now I mentally try to resolve possible porting problems. Second problem is interaction with already existed Genode components. I think that Ipc_istream and Ipc_ostream are the right places. Not sure about signaling though.
Best regards Stefan
The question is: even having that method, can we still consider our tasks "green"? Or such complexity is no better than the ordinal thread complexity?
Thanks!
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
Igor -
Stefan Kalkowski