[erlang-questions] Glossary

[Attila Rajmund Nohl]

2009/7/21, Richard Andrews <bflatmaj7th@REDACTED>:
> On Tue, Jul 21, 2009 at 10:17 PM, Attila Rajmund
> Nohl<attila.r.nohl@REDACTED> wrote:
>> 2009/7/20, Richard Andrews <bflatmaj7th@REDACTED>:
>> [...]
>>>  * All data access is sequential (no race conditions, no mutex
>>> deadlocks).
>>
>> I think this is the number one myth about Erlang. Actually it's fairly
>> easy to create race conditions and deadlocks:
>>
>> Consider a server application which accept connections from the
>> network and executes commands received through this connection. One of
>> these commands is the "exit" command which stops the application.
>> Suppose this application is implemented with two processes, one
>> handling the network protocol, and one executing the commands, etc.
>> What happens, if the client is particulary stupid and sends the "exit"
>> command twice really fast? When the first "exit" comes in, the command
>> handling process exits and notifies the network handler process about
>> this. However, the client could beat this notification with its second
>> "exit" command: the network handling process is still alive and
>> happily accepts the second "exit" command. Then is tries to send the
>> "exit" command to the command handling process, but that's already
>> gone, so one gets a huge crash report due to the race condition. This
>> is a problem I'm currently working on.
>>
>> An other common error is two gen_server processes calling each other:
>> a deadlock. Even though Erlang processes do not share memory, the
>> application could share state among processes and there you've got the
>> same problems of deadlocks, race conditions, etc.
>
> This is all very contrived.
> Yes it is - strictly speaking - possible. I admit to hyperbole. But in
> practice for me it just doesn't happen because I obey a few simple
> rules of practice.

Of course, I wanted to send it to the list the first time... The race
condition I've described above very much exists in the OTP SSH server.
 There was also a thread here recently about trying to trace the
erlang shell and that lead to a deadlock.

In my experience these bugs do happen in Erlang programs and it's
sometimes quite hard to find the cause - just like with race
conditions and deadlocks in other languages.