Tune delays in user_sup #4895
Tune delays in user_sup #4895
Conversation
| @@ -108,7 +111,8 @@ wait_for_user_p(N) -> | |||
| link(Pid), | |||
| {ok, Pid}; | |||
| _ -> | |||
| receive after 100 -> ok end, | |||
| %% minimal sleep so the shell is not delayed more than needed | |||
| receive after 1 -> ok end, | |||
There was a problem hiding this comment.
I wonder if there is a way to make 'user' send a reply back instead of busy-wait loop.
There was a problem hiding this comment.
Yeah, I don't like the "wait for name to become registered" method. Adding proper synchronization would be more elegant, but obviously a bigger change, and I wasn't sure if there was a reason somewhere for not relying on the user process to send an ack.
I'm not particularly worried about the busy-waiting though. A millisecond is still a fairly long time in this context.
There was a problem hiding this comment.
When user is called (i.e. when a non-interactive shell is started) the name should always be registered when the apply returns as far as I can tell. However, for interactive shells user_drv is called which registers the user name asynchronously which is why the spinning is needed. At least that is how I read the code.
@richcarl Did you find the delay also in non-interactive shells?
There was a problem hiding this comment.
No, there is no delay when using -noshell. This is still worth doing something about, because you can feel those extra 100 ms between typing 'erl' and getting the interactive shell prompt.
There was a problem hiding this comment.
@garazdawi And yes, the user_drv process is spawned off and does its own registration, whereas the user.erl start code spawns the process and does the registration before returning. If there's no particular reason for letting these behave as they like, it would be straighforward to make both do a synchronized start.
There was a problem hiding this comment.
If there's no particular reason for letting these behave as they like, it would be straighforward to make both do a synchronized start.
No reason that I can think of. We already synchronize today by spinning on the name, so might as well make the sync more explicit by making user_drv send an ack when it knows that user exists.
There was a problem hiding this comment.
Do you want to try to implement ack for user_drv, or should we go with your current solution at the moment?
richcarl
force-pushed
the
tune-delays
branch
from
3312f28
to
860257f
Compare
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
|
Fixed in #6144 |
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
In order to avoid spinning in `user_sup` we start user during the synchronous phase of `user_drv` startup. See erlang#4895 for more details
Discovered while investigating startup and shutdown times:
These patches are mainly meant as suggestions.