[Barrelfish-users] One question about the bootup process

[Baumann Andrew]

Hi,

> As I understood from the code, binding with the local monitor is performed
> during the bootup process for the domains that are not initial (all except init,
> monitor and mem_serv) through the method "monitor_client_lmp_bind" in
> lib/barrelfish/monitor_client.c. It consists of  sending the endpoint to the
> monitor, registering for receive events and performing the continuation
> which in this case only sets the variable request_done = true. When the
> bootup process continues there is a while-loop that confused me, given
> below (method "barrelfish_init_onthread" in lib/barrelfish/init.c):
> 
>     request_done = false;
>     err = monitor_client_lmp_bind(mcb, monitor_bind_cont,
> &init_complete_err,
>                                   default_ws, DEFAULT_LMP_BUF_WORDS);
>     if (err_is_fail(err)) {
>         return err_push(err, LIB_ERR_MONITOR_CLIENT_BIND);
>     }
> 
>     // dispatch events on the waitset until monitor binding completes
>     while (!request_done) {
>         err = event_dispatch(default_ws);
>         if (err_is_fail(err)) {
>             return err_push(err, LIB_ERR_EVENT_DISPATCH);
>         }
>     }
> 
> My question, is there a possibility of reaching the while loop with boolean
> value still being false?

No, in the current implementation monitor_client_lmp_bind() always succeeds and immediately runs the continuation, but there is nothing in the API contract that guarantees this behaviour.

> And if so (monitor binding is still not complete), which
> events can be dispatched on the waitset since even monitor binding is not
> complete at that stage?

I could imagine an implementation where setting up the monitor binding may involve handling a sequence of low-level connection-setup messages. In this case the continuation and the dispatch loop would be required.

> I am asking because I think that while-loop is not
> needed at all, and if that's not true than I am missing something fundamental
> here.

Like I said, there are no other messages that could come in, but that doesn't prevent a future implementation of  monitor_client_lmp_bind from using the continuation -- indeed, if you look at the current implementation you'll see a FIXME which indicates on source of possible asynchrony which would require it.

Cheers,
Andrew