The process supervised and the process owning the socket may be different

[essen]

RabbitMQ for example starts a number of processes when a connection gets accepted. The top level process (that we need to supervise) is itself a supervisor (which we can already accept fine). But it's not the process that will read from the socket, one of its children is. So it could be very nice if we allowed returning two pids, one for the process to be supervised, and one for the process that will do the reading.

Should be done in Ranch 2 in #111.

Also related to rabbitmq/rabbitmq-server#260.

[essen]

Will do that in 1.2.0, it's a new feature and doesn't break anything.

[essen]

Straightforward enough except on what to do when the controlling_process call fails.

[essen]

Solution: kill.

Docs should make clear that the process gets killed brutally, and if that's not what the user wants they should synchronize sensitive processes after accept_ack returns.

[essen]

Should only be enabled when the connection_type value is set to supervisor. This makes no sense to supervisor a worker but have a separate process handle the socket.

[essen]

Done, tests need to be written next though.

[essen]

Looks to be working in RabbitMQ.

[essen]

Done in 52797b0 except I forgot the tests. Oops. :-)

[essen]

Tests are in. Closing!