Hacker News Reader

Comment by nodesocket | Hacker News Reader

"The way it's handled is that the process where the previous socket was connected remains in place until it terminates but all new sockets connect to the new code."

That would imply that two separate processes are bound to the same port right? I thought that was not possible.

View on HN

No, usually there's an accept process spawning working processes and passing the connection off to it.

Erlang can have two versions of a module present in memory at a time. At the moment of a code upgrade, the processes working with existing connections continue to use the old code while newly accepted connections are passed to the version of the module that was loaded in between connection accepts.

Keep in mind that Erlang processes != System processes. Erlang processes are preemptively scheduled microthreads that are scheduled by the Erlang VM.

Things have changed :)

https://lwn.net/Articles/542629/

If only the JVM could take advantage of this.

Just about bet you could do that via some grotesque JNI work, but I wouldn't wish JNI on really anyone.

While there are certain socket options to share a port - two processes can share a port easily in another elegant way; just call fork().

One way of doing such upgrades is then for the existing code to fork() then exec() the new version. The existing old code closes the original server socket, which leaves accepting new requests to the new code. When all in-flight requests served by the old code is finished, that process can exit.

Presumably the original server process uses exec() to start the new process, which inherits the open socket handles, and the descriptor is passed as an argument to the new process.

(e.g. http://stackoverflow.com/questions/14351147/perl-passing-an-...)

Reply on news.ycombinator.com