Hi all,
during my work, I've written a vesa driver which is capable of serving multiple clients (using 'virtual' framebuffers, derived from your vesa_drv).
I always thought, that my 'Session_component' is created once when the first client opens a connection to my service, so that init calls 'create_session' in my 'Root_component' just once and never again.
That was obviously wrong. I've found out, that 'create_session' is called once for each client - not on creation of the connection but on the first ipc call the client invokes.
For my setting, this behaviour is not useful, so I've manually taken care of being a singleton by allocating my 'Root_component' only once in 'create-session' and handing out that single object subsequently on each following session creation.
I've noticed some strange behaviour with that setting.
(1) I saw that something complained about my singleton -- [init -> vesa_drv] void Genode::Avl_node<NT>::insert(Genode::Avl_node<NT>*) [wit h NT = Genode::Object_poolGenode::Server_object::Entry]: Inserting element 26f c twice into avl tree! --
But that did not seem to matter, so I ignored it...
(2) I had to identify my clients somehow to maintain state information. So I hand over a 'shared secret' in each ipc call. That's simply the dataspace cap the client got from me.
I noticed that something else than my clients called one of my methods during startup with an invalid secret.
-- [init -> vesa_drv] virtual void Framebuffer::Session_component::toggle(Genode::D ataspace_capability): Framebuffer::Session_component::toggle 4b383d61h [init -> vesa_drv] virtual void Framebuffer::Session_component::toggle(Genode::D ataspace_capability): Framebuffer::Session_component::toggle: _fb_cap not accept ed. --
I wonder who might that be. Maybe a relict of mine or does the framework some kind of 'reflection'?
(3) However, all that did not really bother, and for a start, everything seemed to work nice, but when my setting grew bigger, some ipcs didn't work properly.
One of my two clients (the 2nd) caught an 'Ipc_error' when performing its second request. The first request performed fine. I thought that maybe the ipc could not be performed because the Session_component was serving another ipc at that moment. So I've ignored the exception and i kept retrying the ipc call. Without any success, and from here on I can't imagine what happens.
Does anyone have an idea what I've missed?
Kind regards
Sven -- Sven Fülster