Restoring child with checkpointed state

[David Werner]

Hi Stefan,

>> As being said, this specific IRQ object is part of the SIGNAL session
>> and its client state. I'm not sure how your restore mechanism works
>> exactly, but if work is done within the component that gets restored,
>> you can do the re-attachment there. Otherwise, you would need to change
>> the request_semaphore call. So that the information of which thread gets
>> attached is part of the server side in core. Instead of attaching to the
>> IRQ object itself, the signal handler thread transfers its identity to
>> core via request_semaphore. Core attaches the thread and delivers the
>> capability. Whenever request_semaphore is called, you detach formerly
>> attached threads, as well as when the session is closed.
>> Does that make sense for you?
At the moment the l4_irq_attach(...) call takes place in the constructor 
of Signal_source_client.
[/repos/base-foc/src/lib/base/signal_source_client.cc].

The call needs two Fiasco::l4_cap_idx_t (kcap) to determine the IRQ 
object and the thread which should be attached to it.

When moving the l4_irq_attach call to the server side, these kcaps are 
obviously different to the ones at client side.
For the IRQ i simply use the _blocking_semaphore native capability to 
find out the kcap. But i failed to find a way to
determine the kcap of the thread at the server side.

Therefore my question is if you could you go in a bit more detail about 
how you would realize the "transfer its identity to core" part.
Do i have to transfer the  thread name, its capability or something else?

I tried a few things but i couldn't make it work.

Kind Regards,
David