loop exit question

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

loop exit question

Steve Langstaff
On 19 April 2001 13:11, Klacke [SMTP:klacke] wrote:

> On Thu, Apr 19, 2001 at 02:02:43PM +0200, Willem Broekema wrote:
> > If a function should loop forever while remembering some
> > state, most examples I have seen use:
> >
> > loop(State) ->
> >    receive
> >        stop ->
> >            stopped_upon_request;
> >        Other ->
> >            ...,
> >            loop(State)
> >    end.
> >
> > Now, if the State is not changed in any of the 'reveiced'
> > branches, is there a reason not to move the final 'loop()'
> > command to the end, and use 'exit()' for breaking out of
> > the loop, like in the following?
> >
> > loop2(State) ->
> >    receive
> >        stop ->
> >            exit(self(), stopped_upon_request);
> >        Other ->
> >            ...
> >    end,
> >    loop(State).
> >
> >
>
>
> No, that's the way to do it.

Doesn't the action of exit change, depending on whether the process
is trapping exits?

A light perusal of "Concurrent Programming in ERLANG"
seems to suggest that exit will/may cause a process to terminate, whereas
one might just want to drop out of a loop. Or have I misunderstood the
original question?


--
Steve L.




Reply | Threaded
Open this post in threaded view
|

loop exit question

Willem Broekema
Steve Langstaff wrote:

> Doesn't the action of exit change, depending on whether the process
> is trapping exits?
>
> A light perusal of "Concurrent Programming in ERLANG"
> seems to suggest that exit will/may cause a process to terminate, whereas
> one might just want to drop out of a loop. Or have I misunderstood the
> original question?

Indeed, my question was not clear about that. In my situation, the loop
function is
a tcp connection listener, receiving either 'stop', or '{tcp, Sock,
Data}'. The latter
packets are parsed and send to a wrapper, so the loop is always called with
the same arguments:

   connListener(ConnWrapperPid, Sock)

As soon as 'stop' is received, the process may terminate, as this is the
only function
running on the process (it was spawn_link()-ed).

I had not paid attention to exit/1 versus exit/2, so thanks for pointing
out the
important difference. I'll look into it.

Thanks for the fast responses, and the great language... so few lines,
so much
functionality! :-)

- Willem