[e-lang] Proposal: E / Erlang integration

[Ulf Wiger]

Den 2006-06-08 18:04:41 skrev Mark S. Miller <markm@REDACTED>:

> Regarding concurrency control, E's event-loops are non-blocking. By
> contrast, the preferred Erlang style for sending a request and
> receiving a response is for the requesting process to do a blocking
> receive that is receptive only to the alleged response (where the
> alleged response is distinguished from other requests by
> convention). This would seem to leave networks of Erlang processes
> vulnerable to deadlock. Continuing with section 24.2 of my thesis:
>
>> Although Erlang was inspired by Actors, a common programming pattern
>> in Erlang is for a process to block waiting for a reply to a
>> previous request. While blocked, the process is not responsive to
>> other requests. This is like the "message-oriented systems" of Lauer
>> and Needham [LN79] rather than the non-blocking event loops of E.
>
>> [LN79] Hugh C. Lauer and Roger M. Needham. On the Duality of
>> Operating System Structures. In Proc. 2nd International Symposium on
>> Operating Systems, pages 3--19. IRIA, October 1979. ACM Operating
>> System Review.
>  However, if Erlang systems don't seem to be vulnerable to deadlock in
> practice, the Erlang community may not find the above difference
> compelling.

You could read and perhaps comment on my presentation at EUC 05:

Structured Network Programming  
(http://www.erlang.se/euc/05/1500Wiger.ppt), where I take a basic  
telephony problem ("complex concurrency") and implement it both using  
selective receive and in an event-driven, non-blocking fashion. One of the  
things to note is that while it is possible to accomplish low-level  
deadlocks, the application-level concurrency issues are the really hairy  
ones. You may well accomplish an application-level deadlock even with a  
fully non-blocking, event-driven design. These deadlocks are extremely  
difficult to foresee and debug. I argue that non-blocking event-driven  
programming can lead to a complexity explosion in certain situations. This  
is hardly an original idea. Mike Williams, Bjarne Däcker and others wrote  
about this already in the late 70's, I believe (at least in internal  
Ericsson documents.) However, it's not that well covered in teaching  
material.

In Erlang, programmers tend to learn pretty quickly to insert timeout  
guards on receive statements most of the time. If one uses gen_servers,  
there's a built-in 5-second timeout. This way, your processes will crash  
rather than deadlock, which at least gives you a clear indicator that  
something went wrong, and sometimes even lets the program continue.

BR,
Ulf Wiger
-- 
Ulf Wiger