[erlang-bugs] Supervisor terminate_child race

[Bryan Fink]

On Wed, May 15, 2013 at 11:11 AM, Tim Watson <watson.timothy@REDACTED> wrote:
> On 15 May 2013, at 14:54, Siri Hansen wrote:
>
> Then again... it is up to the child's start function to create the link, and
> from the supervisor's point of view, the only place to add the monitor would
> be when the start function returns - which would be just another place to
> get a race :(
>
>
> Well quite. *sigh*

My apologies for dropping out of this conversation. I've been on vacation.

Before vacation, monitoring from the spawn was the best solution I had
come up with as well. But, as has already been pointed out, if it's
not done atomically (which I think can be done with a flag in
spawn_opt, no?), it's just another place for a race. It has also
already been pointed out that changing the supervisor-child contract
for startup isn't really an option anyway.

The only other possibility I see is to guarantee that if an EXIT
message will be delivered, that it is always delivered before any DOWN
message. If this were the case, all receive expressions could have
clauses for both EXIT and DOWN, and simply use whichever arrived
first. Tim's method of checking for EXIT after receiving DOWN would
also work in this case. I assume the problem with this guarantee is
that these messages are generated by different processes, so typical
mailbox ordering rules apply.

Fortunately for my use case, I think that simply linking my children
to their creating process instead of a supervisor may be a viable
option. All of these children are dynamic under a simple_one_for_one
supervisor, and I don't care about restart policies.

-Bryan