[erlang-questions] What I dislike about Erlang

[Evan Miller]

On Sun, Sep 2, 2012 at 9:55 AM, Per Melin <per.melin@REDACTED> wrote:
> On Aug 31, 2012, at 20:57 , Evan Miller wrote:
>
>> A few more comments specific to TinyMQ:
>>
>> On Fri, Aug 31, 2012 at 1:20 AM, Richard O'Keefe <ok@REDACTED> wrote:
>>>  Another documentation failure is that we fail to document what
>>>  is not there.  In TinyMQ, a channel automatically comes into
>>>  existence when you try to use it.  Perhaps as a consequence of
>>>  this, there is no way to shut a channel down.  In TinyMQ, old
>>>  messages are not removed from a channel when they expire, but
>>>  the next time someone does a 'subscribe' (waves hands) or a 'poll'
>>>  or a 'push' *after* they expire.  So if processes stop sending
>>>  and requesting messages to some channel, the last few messages,
>>>  no matter how large, may hang around forever.  I'm sure there
>>>  is a reason, but because it's a reason for something *not* being
>>>  there, there's no obvious place to hang the comment, and there
>>>  isn't one.  (Except for the dead 'expire' clause mentioned above.)
>>>
>>> IT'S HARD TO SPOT SALIENT DETAIL IN A SEA OF GLUE CODE.
>>
>> This probably proves your point, but just to be clear old messages
>> will only "hang around forever" if 1. there are no new messages on a
>> channel and 2. the channel continues to receive requests. If there is
>> no activity on a channel for max_age, the gen_server timeout is
>> invoked here:
>>
>> https://github.com/evanmiller/tinymq/blob/master/src/tinymq_channel_controller.erl#L76
>
> There must be a bug there. You only specify a timeout in the return of init, but that does not persist beyond the first message received. I can't see how that timeout would ever be invoked.
>

Perhaps I am confused, but I thought the gen_server timeout will also
occur between messages.

>
>> That calls "expire" (erasing the reference to the channel) and then
>> exits the supervisor (eliminating the channel and all of its
>> messages).
>
> If you by that mean that it kills the supervisor, it does not. It kills itself, with the supervisor pid as its exit message.

Thanks, that is a bug in the code.

>
> Either way, why do you create a new supervisor for each channel, and why do you create it outside the supervisor tree (i.e from a gen_server and not another supervisor)? What purpose does it serve?
>

The gen_server does "double duty" as a controller and a supervisor;
this is poor design on my part. There should probably be a single
supervisor process for all the channels, monitored by the same
supervisor that monitors the main controller.


-- 
Evan Miller
http://www.evanmiller.org/