Session mapping 1:1 vs. 1:n

[Sven F. <mx...@sv...>]

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_pool<Genode::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