[rabbitmq-discuss] Creating an auth plugin (Kerberos)

[Simon MacMullen]

On 15/11/12 07:22, Simon Lundström wrote:
>> You don't want to add that message to the existing receive block -
>> since you will receive the {Port, {exit_status, A}} message as well,
>> and you'll only receive one message per receive block. So you need a
>> second block after the first to receive the 'EXIT' message.
>
> Aaah, of course! As I've said (a few times now), I'm new to functional
> (and sort of new to event driven) programming.
>
> In my code which I created before I put it in the module I had a loop
> which iterated over receive, is this the prefered solution?

I wouldn't loop, because you know you are going to receive exactly two 
messages. Looping obscures that.

(Also your loop is not tail recursive, see 
http://www1.erlang.org/doc/reference_manual/functions.html#id74170. 
Although that's not the most important thing.)

>>> Since the crash report mentions a supervisor I suspected it had
>>> something to do with "my" sup in
>>
>> No, not at all. The crash report mentions a supervisor since pretty
>> much all crash reports do - the supervisor *for the reader* detected
>> that the reader had crashed.
>>
>> After all, that's what supervisors are for.
>
> Still new to Erlang and it's stacktraces, but since I've "created" my
> own supervisor how come it isn't mentioned in the stacktrace? Or is "my"
> supervisor just a shim of sorts?

Your supervisor isn't involved - it's just there so that the application 
has something to launch. You could convert your plugin to a library 
application by removing {mod, ...} from the app descriptior, and remove 
the _app.erl, and have no supervisor.

(search for "library application" in: 
http://www.erlang.org/doc/design_principles/applications.html)

The rabbit_auth_backend is a callback, invoked by rabbit_reader, so it's 
that process's supervisor that matters.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware