ets table inheritance and trap_exit message

Question

Reading "Learn You Some Erlang" I discovered that I can set a process heir for given ets table that will receive the message:

{'ETS-TRANSFER', TableId, FromPid, Data}

when the process owning the table dies.

After a while I found this post with different suggestion on how to preserve the ets table using such feature.

In the last method the user suggests to use also trap_exit in order to know whether the peer process owning the table is dead. Now my question is: which message do I receive first? The message about the ets table or the one about the crash of the peer process?

Is it really necessary to handle the exit message? When I receive the ets message I know that the peer process handling it is dead right? Or is it still alive for some time?

Answer 1

According to the post, after give_away, if the creating process dies, the process SomeOtherProcess will receive a message of the form {'ETS-TRANSFER', TableId, OldOwner, GiftData} is wrong. When give_away/3 is called, immediately the SomeOtherProcess becomes new owner process and receives this message even if the creator is not dead.

As you told it is not really necessary to handle exit signal also, but you may want to do any other operations on receiving the exit message. (Also handling give_away chains, getting back the table back to creator from owner etc)

Usually what I have come across is that 'ETS-TRANSFER' message comes before 'EXIT' but we cannot reply on this. Hence as Roberto Aloi has mentioned, we can do selective receive. Selective receive is achieved using nesting receive. Example

receive
    {'EXIT', Pid, Reason} ->
        receive
            {'ETS-TRANSFER', TableId, OldOwner, HeirData} ->
                got_table
        after 0 ->
                ignore
        end 
after 0 ->
        ignore
end.

LearnYouSomeErlang has good explanation of selective receive and why/how to avoid it to give priority to messages received.