IRC channel logs


back to list of logs

<damo22>i meant after the fsys_init call, the ess_task list seems empty
<youpi>doesn't record_essential_task get called?
<damo22>record_essential_task gets called for all the processes
<damo22>but it gets called after the launch_core_servers
<damo22>so i cant check the existance of the list members until after
<damo22>or maybe it is happening asynchronously to the flow of the launch_core_servers
<damo22> /* Tell the proc server our msgport. Be sure to do this after we are all done making requests of proc. Once we have done this RPC, proc assumes it can send us requests, so we cannot block on proc again before accepting more RPC requests! However, we must do this before calling fsys_init, because fsys_init blocks on exec_init, and exec_init will block waiting on our message port. */
<damo22>i moved the proc_child requests below that fsys_init
<damo22>except the authtask and fstask, because it hit EPERM without it
***Server sets mode: +nt
***Server sets mode: +nt
<youpi>i.e. fsys_init not getting called from fsys_init, but after that
<youpi>ah, wait
<youpi> /* startup is single-threaded, so we must reply to its RPC before doing
<youpi> anything which might attempt to send an RPC to startup. */
<youpi> fsys_init_reply (reply, replytype, 0);
<youpi>that's why
<damo22>so i have to send the reply before calling it again?
<youpi>that would bring mess
<youpi>I'd say rather move the proc_child call into startup_essential_task
<damo22>so just after frob_kernel_process () ?
<youpi>no need to wait for authinit/execinit/procinit
<youpi>ah, wait, you need procinit actually
<youpi>so it'd be :
<youpi>along procinit=1, go through the list that was already recorded, and proc_child() them
<youpi>and if proc_init==1, you can directly proc_child() it
<youpi>so as to proc_child() those that got before proc, and proc_child() those that get after proc
<damo22>along procinit=1 there are no processes recorded except proc itself
<youpi>that's only a mishap
<youpi>I mean, you never know how things couldb e ordere in the future
<youpi>so better be safe
<damo22>but i do exclude proc from proc_child
<damo22>otherwise its a mess
<youpi>you need to avoid making proc a child of itself yes
<damo22>i think there are even more tasks registered after procinit==1
<damo22>can i put the proc_child call in register_essential_task?
<damo22>i mean record_essential_task